4 ms·

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-taugh

by fibbery 12y ago

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.

yid 12y ago
> Do you have any thoughts on how a junior engineer can improve their ability to write maintainable code? Think of your code like an essay. Write comments on the motivation for decisions you make, not just what the codes does. Think of the exercise not as trying to just produce writing code, but to make the next person reading the code feel like they were with you the whole way, making decisions together, working out problems on a whiteboard. While doing this, don't be afraid of honesty, don't be afraid of verbosity, and always have empathy for the next person reading your code.
finder83 12y ago
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.
singold 12y ago
I'm far from what I would call a senior engineer (or a engineer at all), but the times I've written the most readable and maintainable code were when I write first what the program should do in comment form and then completed it with the corresponding code. This way you force yourself to think outside your programming language and also forces you to write the corresponding comments. I think this has a name as a methodology but cant remember it.
pja 12y ago
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.

by fibbery 12y ago

yid 12y ago

> Do you have any thoughts on how a junior engineer can improve their ability to write maintainable code? Think of your code like an essay. Write comments on the motivation for decisions you make, not just what the codes does. Think of the exercise not as trying to just produce writing code, but to make the next person reading the code feel like they were with you the whole way, making decisions together, working out problems on a whiteboard. While doing this, don't be afraid of honesty, don't be afraid of verbosity, and always have empathy for the next person reading your code.

finder83 12y ago

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.

singold 12y ago

I'm far from what I would call a senior engineer (or a engineer at all), but the times I've written the most readable and maintainable code were when I write first what the program should do in comment form and then completed it with the corresponding code. This way you force yourself to think outside your programming language and also forces you to write the corresponding comments. I think this has a name as a methodology but cant remember it.

pja 12y ago

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.