I wanna get good. Where to start?
February 21, 2017 2:25 PM Subscribe
I feel like I am a decent enough programmer, but I want to really rekindle my passion for the craft and work towards becoming great - a sort of Renaissance (wo)man developer. Book, blog, and online resource recommendations would be appreciated.
I got my CS degree in 2012 and got the opportunity to work in an exciting high-complexity environment right of school. I completely blew it for a variety of reasons. I did not get fired, but I left it feeling like I learned very little and did not live up to my potential.
I'm in an easier job now and I've learned a lot about how to be more successful professionally, as well as more about tools and ecosystems that I feel my degree left me unprepared for. However, I feel like the skill ceiling for my position now is pretty low.
What I would like to work towards is becoming a "full stack" expert for web applications. I have a few projects in mind to help with the learning process, and although I realise a lot of it will be tinkering and following tutorials and so on, I would also appreciate some more in-depth resources - my ultimate goal is to understand something literally top-to-bottom.
Suggestions of resources or communities online, blogs of experts, and books are all appreciated.
Right now I'm particularly interested in the nitty-gritty of JavaScript, Clojure, modern computer networking, and cloud/service architecture. In the future I would like to pursue compilers and reverse-engineering.
General resources that are language or service-agnostic are fine as well - practical applications of CS concepts, algorithm design, software development methods, good practices and patterns, etc.
Anything that brought you from good -> great with regards to your programming knowledge and application, with real effects on how you worked in practice, is appreciated.
I got my CS degree in 2012 and got the opportunity to work in an exciting high-complexity environment right of school. I completely blew it for a variety of reasons. I did not get fired, but I left it feeling like I learned very little and did not live up to my potential.
I'm in an easier job now and I've learned a lot about how to be more successful professionally, as well as more about tools and ecosystems that I feel my degree left me unprepared for. However, I feel like the skill ceiling for my position now is pretty low.
What I would like to work towards is becoming a "full stack" expert for web applications. I have a few projects in mind to help with the learning process, and although I realise a lot of it will be tinkering and following tutorials and so on, I would also appreciate some more in-depth resources - my ultimate goal is to understand something literally top-to-bottom.
Suggestions of resources or communities online, blogs of experts, and books are all appreciated.
Right now I'm particularly interested in the nitty-gritty of JavaScript, Clojure, modern computer networking, and cloud/service architecture. In the future I would like to pursue compilers and reverse-engineering.
General resources that are language or service-agnostic are fine as well - practical applications of CS concepts, algorithm design, software development methods, good practices and patterns, etc.
Anything that brought you from good -> great with regards to your programming knowledge and application, with real effects on how you worked in practice, is appreciated.
I tried to write up something about tools and ecosystems for the the "full stack" web developer many years ago and maintained it for a while: "So you want to be a web developer?" I know you'd like to focus on how things are today versus ~8 years ago, but a few links are still relevant--especially those at the top linking to current resources like (MeFi's own) Dudley Storey's The New Code or to Awesome Awesomeness (curated lists of resources relevant to specific technologies).
For more general pointers about getting good at programming, you might look at Dan Luu's "How I learned to program" (which links to many similar narratives), "Modest list of programming blogs," and "Programming books you might want to consider reading." I think they're all fairly recent write-ups, even if they describe things that are classics. Lobste.rs is also a reasonably nice community of programmers worth following.
posted by cpound at 5:21 PM on February 21, 2017 [1 favorite]
For more general pointers about getting good at programming, you might look at Dan Luu's "How I learned to program" (which links to many similar narratives), "Modest list of programming blogs," and "Programming books you might want to consider reading." I think they're all fairly recent write-ups, even if they describe things that are classics. Lobste.rs is also a reasonably nice community of programmers worth following.
posted by cpound at 5:21 PM on February 21, 2017 [1 favorite]
I like Dan Luu's lists a lot. On computer networking: I really enjoyed Networking for System Administrators, and High Performance Browser Networking (free).
NAND to Tetris is a neat-looking book that takes you from circuit design to assembly language to writing a compiler to writing a game.
Some favorite programming blogs: Rachel by the Bay has wonderful debugging stories, Programming in the 21st Century, Lara Hogan (blog) is now a manager but previously did web performance and wrote a really interesting-looking book called Designing for Performance on web performance, Aphyr has a really good distributed systems blog, the morning paper has an academic paper every day, Andy Wingo works on compilers for fun and has an interesting blog about it. This article on writing software without a compiler is great.
The point for me where I felt like I "got" how to learn stuff on my own in my programming career and become more of a 'renaissance woman' was after I went to the Recurse Centre. It's by far my favorite programming community (and very much in the "my ultimate goal is to understand something literally top-to-bottom." spirit). I went 2 years after finishing a CS degree (and I wrote 50 blog posts about what I learned there). But you have to go to New York for 6-12 weeks which is not possible for everyone.
posted by oranger at 7:35 PM on February 21, 2017 [6 favorites]
NAND to Tetris is a neat-looking book that takes you from circuit design to assembly language to writing a compiler to writing a game.
Some favorite programming blogs: Rachel by the Bay has wonderful debugging stories, Programming in the 21st Century, Lara Hogan (blog) is now a manager but previously did web performance and wrote a really interesting-looking book called Designing for Performance on web performance, Aphyr has a really good distributed systems blog, the morning paper has an academic paper every day, Andy Wingo works on compilers for fun and has an interesting blog about it. This article on writing software without a compiler is great.
The point for me where I felt like I "got" how to learn stuff on my own in my programming career and become more of a 'renaissance woman' was after I went to the Recurse Centre. It's by far my favorite programming community (and very much in the "my ultimate goal is to understand something literally top-to-bottom." spirit). I went 2 years after finishing a CS degree (and I wrote 50 blog posts about what I learned there). But you have to go to New York for 6-12 weeks which is not possible for everyone.
posted by oranger at 7:35 PM on February 21, 2017 [6 favorites]
Hi, I'm a professional engineer with 15+ years of experience. I work the "full stack" at my job because I'm the only full-time engineer there (very small company). I inherited my app about 8 years ago and have spent the time in between revamping it completely as well as building new stuff that wasn't part of its original feature set. I'll write a little bit about how I do what I do; I'm sure I'll leave some stuff out but hopefully this will be of some help. In no particular order:
1) Read other people's code. Reverse engineering and fixing others' code is a difficult skill but massively useful. It's especially hard when you can't just ask them "what is this supposed to do?" but that's the best way to get good at it. Reading other people's code will teach you new tricks (if they're good programmers) as well as show you what to avoid. It also will enable you to discern the function of a thing from the bottom up (rather than top-down) which is an incredibly useful thing to be able to do when delving into uncharted waters (e.g., you're tasked to fix Hank's module 6 months after he died in a tragic pogo stick accident).
2) Read in general (about technology). My go-to for encountering a problem I don't already know the answer to (e.g., how to get software X to work on Y platform it wasn't intended for, or what to do about cryptic error message Z) is of course the lowly google search. But you'd be surprised how your google-fu will affect your ability to effectively solve a problem. The internet is where I store all the things I don't want to have to remember; so long as I can google it up quickly, I don't have to commit it to memory.
3) Read the documentation, but not too much. One of the more useful skills is being able to identify where in the documentation the solution to your problem lies. The more experienced you get, the less you'll be inclined to want to read an entire set of documentation, or even a whole chapter. A lot of documentation tends to share similar structure, or repeat patterns, so learn how to identify that and use it to skip ahead to the part you need. At first, spending more time reading documentation may prove valuable in that it can also teach you best practices for system design, as you start to notice similarities across different sets of documentation.
4) Learn the full computational stack. My university program (umich... go blue!) was designed in a way that may seem sort of old-school at some places now, but an emphasis was placed on well-roundedness. You had to take hardware courses, and a broad enough swath of software courses that by the time you graduated you knew how a computer works from transistor level on up. That's not to say you were an expert at everything, but you understood what words like "pipelining" and "loop unrolling" meant. I get the sense from your answer that you may not, which doesn't prevent you from being a developer, but it does prevent you from being a better one.
5) It's all about abstraction. Some wise person once said "CS is the science of abstraction" or words to that effect. Learning how to squint at two problems and see them as two aspects of the same generalized problem is a great tool. And also that a good implementation by somebody else is one you can use without knowing the nitty gritty details (i.e., the API makes sense). Any time you find yourself solving the same problem over again, it's time to examine whether it makes sense to build a utility that lets you avoid writing that code a 3rd time. My code always has attendant utility classes that make my life easier (once I'm done writing them) but you have to figure out what things are worth that extra effort.
6) If you're dedicated enough, read the classic stuff, like Knuth's The Art of Computer Programming and Kernighan & Richie's The C Programming Language. Particularly the former, which is like the bible of algorithms.
7) Don't write code you don't have to. There are lots of libraries in the world, and usually you want to see if someone else has solved the problem and thrown the answer up on github/stackoverflow/etc. before you go and fix it yourself. Avoid NIH (Not Invented Here) syndrome, but also examine potential other options critically -- importing someone's badly-done library may make your life worse.
8) Allow yourself to make mistakes. There's no such thing as bug-free code, you're human and fallible, and just build that into your worldview so you don't get down on yourself when bugs crop up. As you build experience hopefully you learn not to repeat old mistakes, but there are always new mistakes to make so never rest on your laurels either.
9) Automate maintenance and similar things. For example, I get about 100 emails a day from various automated processes/cron jobs. That represents a lot of stuff getting done for "free" but also an opportunity to spend a lot of time sorting through repetitive email. This is why we invented mail filtration. Every time I check code in, I get an email, and the code is checked for obvious problems (test failure, failure to compile).
10) Testing! Unit testing is your friend. So are sanity checks for data.
11) Assuming you work somewhere where you're not the sole developer like me, code reviews are super useful and great learning experiences. It can be stressful to have senior developers critique your work, which depending on your disposition may also help improve it.
12) Speed programming / competitive programming. This was a thing I did in college and a little afterward but haven't paid attention to in years, so I'm not sure how relevant/popular it still is. But it's a great source for short exercises that can sharpen your skills. It'll also make you study up on math if that's not your strong suit, which has good feedback effects on your generalized programming abilities.
Hope this helps.
posted by axiom at 8:55 PM on February 21, 2017 [8 favorites]
1) Read other people's code. Reverse engineering and fixing others' code is a difficult skill but massively useful. It's especially hard when you can't just ask them "what is this supposed to do?" but that's the best way to get good at it. Reading other people's code will teach you new tricks (if they're good programmers) as well as show you what to avoid. It also will enable you to discern the function of a thing from the bottom up (rather than top-down) which is an incredibly useful thing to be able to do when delving into uncharted waters (e.g., you're tasked to fix Hank's module 6 months after he died in a tragic pogo stick accident).
2) Read in general (about technology). My go-to for encountering a problem I don't already know the answer to (e.g., how to get software X to work on Y platform it wasn't intended for, or what to do about cryptic error message Z) is of course the lowly google search. But you'd be surprised how your google-fu will affect your ability to effectively solve a problem. The internet is where I store all the things I don't want to have to remember; so long as I can google it up quickly, I don't have to commit it to memory.
3) Read the documentation, but not too much. One of the more useful skills is being able to identify where in the documentation the solution to your problem lies. The more experienced you get, the less you'll be inclined to want to read an entire set of documentation, or even a whole chapter. A lot of documentation tends to share similar structure, or repeat patterns, so learn how to identify that and use it to skip ahead to the part you need. At first, spending more time reading documentation may prove valuable in that it can also teach you best practices for system design, as you start to notice similarities across different sets of documentation.
4) Learn the full computational stack. My university program (umich... go blue!) was designed in a way that may seem sort of old-school at some places now, but an emphasis was placed on well-roundedness. You had to take hardware courses, and a broad enough swath of software courses that by the time you graduated you knew how a computer works from transistor level on up. That's not to say you were an expert at everything, but you understood what words like "pipelining" and "loop unrolling" meant. I get the sense from your answer that you may not, which doesn't prevent you from being a developer, but it does prevent you from being a better one.
5) It's all about abstraction. Some wise person once said "CS is the science of abstraction" or words to that effect. Learning how to squint at two problems and see them as two aspects of the same generalized problem is a great tool. And also that a good implementation by somebody else is one you can use without knowing the nitty gritty details (i.e., the API makes sense). Any time you find yourself solving the same problem over again, it's time to examine whether it makes sense to build a utility that lets you avoid writing that code a 3rd time. My code always has attendant utility classes that make my life easier (once I'm done writing them) but you have to figure out what things are worth that extra effort.
6) If you're dedicated enough, read the classic stuff, like Knuth's The Art of Computer Programming and Kernighan & Richie's The C Programming Language. Particularly the former, which is like the bible of algorithms.
7) Don't write code you don't have to. There are lots of libraries in the world, and usually you want to see if someone else has solved the problem and thrown the answer up on github/stackoverflow/etc. before you go and fix it yourself. Avoid NIH (Not Invented Here) syndrome, but also examine potential other options critically -- importing someone's badly-done library may make your life worse.
8) Allow yourself to make mistakes. There's no such thing as bug-free code, you're human and fallible, and just build that into your worldview so you don't get down on yourself when bugs crop up. As you build experience hopefully you learn not to repeat old mistakes, but there are always new mistakes to make so never rest on your laurels either.
9) Automate maintenance and similar things. For example, I get about 100 emails a day from various automated processes/cron jobs. That represents a lot of stuff getting done for "free" but also an opportunity to spend a lot of time sorting through repetitive email. This is why we invented mail filtration. Every time I check code in, I get an email, and the code is checked for obvious problems (test failure, failure to compile).
10) Testing! Unit testing is your friend. So are sanity checks for data.
11) Assuming you work somewhere where you're not the sole developer like me, code reviews are super useful and great learning experiences. It can be stressful to have senior developers critique your work, which depending on your disposition may also help improve it.
12) Speed programming / competitive programming. This was a thing I did in college and a little afterward but haven't paid attention to in years, so I'm not sure how relevant/popular it still is. But it's a great source for short exercises that can sharpen your skills. It'll also make you study up on math if that's not your strong suit, which has good feedback effects on your generalized programming abilities.
Hope this helps.
posted by axiom at 8:55 PM on February 21, 2017 [8 favorites]
For most of what you want to learn, books... are going to leave you short. If you're able to jump jobs to somewhere with Coworkers You Can Learn From, that's the ideal; you'll learn more in less time with equal effort.
If you stop learning, find a new job in the next year; stagnation eventually means you're outta work, anyways.
That said, a few recommendations:
- For "be a better teammate", the book Debugging Teams is good, as is The Pragmatic Programmer.
- For "write better code", the book Code Complete is solid.
- For Javascript, you probably want to read Javascript: The Good Parts. This is the full-depth version of how Javascript works.
- Not a book: probably learn Python; it's the one language that's quick to learn that every last company seems to use somewhere.
An approach-with-caution recommendation:
- For network nitty gritty, Unix Network Programming, Volume 1... but wow, it's dense. If you want to know everything about TCP/IP, though, it's The book.
Anti-recommendations:
- Contradicting someone above, don't read Knuth unless you're currently PhD ready. There are other books you'll learn more from in the same amount of time; Cormen's (CLR) Algorithms is lighter, and Sedgewick's book is even more approachable.
- Avoid spending too much time on design patterns. While they're super useful in a pinch, they're often applied about 100x too much (or too soon!), which mucks up code that shouldda been simpler.
posted by talldean at 10:39 PM on February 22, 2017
If you stop learning, find a new job in the next year; stagnation eventually means you're outta work, anyways.
That said, a few recommendations:
- For "be a better teammate", the book Debugging Teams is good, as is The Pragmatic Programmer.
- For "write better code", the book Code Complete is solid.
- For Javascript, you probably want to read Javascript: The Good Parts. This is the full-depth version of how Javascript works.
- Not a book: probably learn Python; it's the one language that's quick to learn that every last company seems to use somewhere.
An approach-with-caution recommendation:
- For network nitty gritty, Unix Network Programming, Volume 1... but wow, it's dense. If you want to know everything about TCP/IP, though, it's The book.
Anti-recommendations:
- Contradicting someone above, don't read Knuth unless you're currently PhD ready. There are other books you'll learn more from in the same amount of time; Cormen's (CLR) Algorithms is lighter, and Sedgewick's book is even more approachable.
- Avoid spending too much time on design patterns. While they're super useful in a pinch, they're often applied about 100x too much (or too soon!), which mucks up code that shouldda been simpler.
posted by talldean at 10:39 PM on February 22, 2017
Seconding the Recurse Center, which I attended as well and blogged about as I attended. It's free to attend. Also, you mentioned you're a woman -- they have grants to support women's living costs for the 6-12 weeks of attendance. If you ask your job whether you can go on a 12-week unpaid sabbatical to become a better programmer they have many incentives to say yes.
posted by brainwane at 6:57 AM on February 23, 2017
posted by brainwane at 6:57 AM on February 23, 2017
I'm also a woman who attended the Recurse Center and it was amazing. It's definitely provoked the biggest change to how I think about programming and how I get better at programming. Strongly, strongly recommend seeing if you can swing it.
posted by squasher at 8:46 PM on February 27, 2017
posted by squasher at 8:46 PM on February 27, 2017
This thread is closed to new comments.
posted by one of these days at 3:03 PM on February 21, 2017