How to become a programmer, or the art of Googling well

Googling well is very helpful in filling in gaps in your knowledge that are widely known by others. For most (?) software engineering jobs, that's probably enough.

Writing some code that works, though, doesn't forward the state of the art. I was lucky enough to take AP computer science in high school. I remember arguing with the teacher when she criticized my code in front of the class. I said something along the lines of "Well, it runs and produces the right output!" She then lit into me, explaining that the structure of the code, its readability and maintainability were at least as important as its output. I've carried that lesson with me in the 19 years since, and had in reinforced multiple times over.

The art of "Googling well" won't teach you good abstraction and maintainability, and yet I would argue it is one difference between junior engineers and (good) senior engineers. We talk about learning all these frameworks, but that's not nearly as useful as developing the skills to create the next powerful abstraction to make a class of hard or time-consuming problems easier or faster to solve. You won't learn how to do that on Stack Overflow.

Do you have any thoughts on how a junior engineer can improve their ability to write maintainable code? This is the main problem I struggle with as a self-taught developer. I can write code that works for the most part thanks to googling all the things, but my projects tend to turn to spaghetti the longer I work on them, and are greek to me when I return to them in 6 months.

Part of the issue is that it's much more rewarding to add a new shiny feature than it is to refactor the existing mess, but another part is I'm not really sure what goes where. Most online courses targeted at inexperienced programmers teach x feature of y programming language, instead of practical software engineering... as a result I feel like I've learned how to build a fancy stained glass door for a house that has an unstable foundation.

I've often thought I'd like to hire a senior dev to sit with me and help me work through building an app the 'correct' way... but short of that I'd love to know of any books or web resources that would help.

I was also self-taught and it took a good 2 years for me to get to the point to be able to write maintainable code. Here are the lessons I learned, in no particular order:

1.) Read your code after you write it. I do this via git diff --cached. It's amazing how many bugs you catch this way. Be critical of variable names, code layout or confusion, lack of documentation. It's basically doing your own code review. Is it documented? Is it tested? Does it make sense logically? Is it easy to read?

2.) Document stuff. Fluff documentation is even fine to start with, you'll eventually learn to separate the important documentation from fluff. Ultimately you need to get to the point of the "why" code does what it does, not the "what" it does. "What" it does should be evident by the code itself and the variable names/etc.

3.) Plan ahead. I don't mean pseudo-code per-se...more thinking or writing down how code will fit together. Mind mapping is great for this, particularly with a white board or tile. I have a Galaxy Note that I bought partially for this purpose and use Papyrus for it now. Basically, how do the abstractions and parts fit together? Is it logical? Not everything requires a whiteboard, but a few minutes of thinking ahead can help spaghetti code a lot.

4.) Learn different programming paradigms. OO style can quickly become un-maintainable even to pros. I suggest learning functional programming in a language like Scheme/Clojure, Lisp, or Erlang. I now pick up a new language every year in different paradigms...not so much to learn the language or to brag, but to learn different way things can be architected, and the way other languages do things.

5.) Do refactor. Outside of budget constraints, don't be afraid to rewrite code that doesn't seem to flow properly.

You mentioned sitting with a senior dev...that was pretty huge for me too, even in limited times. (I'm not sure I'd pay for it, but it did cut the learning curve down quite a bit) Having someone do code reviews of your code that knows what they're doing and invests time in it is helpful too. I've found though that not every Senior dev is good at reviewing code or teaching...

Sorry, I don't have any actual resources for this other than well structured code like Django (mostly) or sqlite. I now have a B.S. in CS and I don't really think they teach this well in schools either. Patterns will only get you so far in OO too...generally, trying new languages, reading code, and refactoring has made the largest impact on me.

"Chance favors those with a prepared mind" is grammatically correct and sounds just fine, it's just not as pithy as the original. You could also say "Chance favors prepared minds".

Read other people's code. There's a world of high quality (and not so high quality!) code out there - pick a reasonably simple open source app and read it's code. Think about how it's put together: Why did the programmer chose to cut the problem space into those particular pieces? How do those pieces interact? Is the API obvious, or completely opaque? Is it completely batshit internally? (I've seen some batshit code in my time. I even wrote some of it.) How could it be improved?

Mentoring with a senior dev is a great idea if you can find someone willing to sit down with you, but just doing the work of going through real world code is well worth your time IMO.