I wish I could embed a Meme because I swear this post can be encapsulated in a Dilbert. Something or other to the effect of "We did a cost benefit analysis to see if cost benefit analysis are useful...we're confused and spent too much time and $ doing them that we don't have to to review the analysis. Great post.
Working as a Software Engineer in a startup-like organization, just out of graduation, with no support from senior engineers I feel it difficult to know when to stop thinking about perfecting my code. I believe that one can never learn a programming language completely, at least with Python. I keep reading the documentation to improve the code, even when I have a lot more work to do. I personally think it is important that my code is following the standards when the client team reads it, but searching about how it's supposed to be done and then improving is taking up too much time. How can I assess the progress and stop making up more work for me?
Great question, Monica! Taking pride in your work, and trying hard to make your code pleasant for other people to read, is a wonderful approach to your career.
Some of us forget that code is a form of writing, and that the human beings who create and maintain it are no less important than its functionality. Maybe that's what happened to the senior engineers on your team. Utilitarianism is a tempting ethos for computer programmers who've been trained to view the world in purely logical terms, but it leads to misery. Thank you for being a light in the darkness.
The short answer to your question—“When should I stop improving the code?”—is that you should stop when you can be of more value by doing something else. Your time and energy are finite, and you have to be as careful spending them as you would be spending money. You won't always know in advance which parts of your work are most valuable; which code will be thrown away next month, and which will be maintained for years to come. You can, however, control your allocations: Like a stock trader balancing her portfolio, you cannot be certain which investments will pay off, and which will be losses, but you can bound your losses by limiting the time you spend on any one task. Diversify your portfolio of contributions. Plant many seeds, then see which take root, and which are not worth watering.
For ideas on managing uncertainty, so that you know (especially at a startup) where to invest your time, take a look at the book The Lean Startup by Eric Ries. To see how a larger team can stay on the same page as it develops a big project over a period of years, read The Mythical Man-Month by Fred Brooks. (The Mythical Man-Month is a great read, even if books on professional development aren't usually your thing.)
I wish I could embed a Meme because I swear this post can be encapsulated in a Dilbert. Something or other to the effect of "We did a cost benefit analysis to see if cost benefit analysis are useful...we're confused and spent too much time and $ doing them that we don't have to to review the analysis. Great post.
Working as a Software Engineer in a startup-like organization, just out of graduation, with no support from senior engineers I feel it difficult to know when to stop thinking about perfecting my code. I believe that one can never learn a programming language completely, at least with Python. I keep reading the documentation to improve the code, even when I have a lot more work to do. I personally think it is important that my code is following the standards when the client team reads it, but searching about how it's supposed to be done and then improving is taking up too much time. How can I assess the progress and stop making up more work for me?
Great question, Monica! Taking pride in your work, and trying hard to make your code pleasant for other people to read, is a wonderful approach to your career.
Some of us forget that code is a form of writing, and that the human beings who create and maintain it are no less important than its functionality. Maybe that's what happened to the senior engineers on your team. Utilitarianism is a tempting ethos for computer programmers who've been trained to view the world in purely logical terms, but it leads to misery. Thank you for being a light in the darkness.
The short answer to your question—“When should I stop improving the code?”—is that you should stop when you can be of more value by doing something else. Your time and energy are finite, and you have to be as careful spending them as you would be spending money. You won't always know in advance which parts of your work are most valuable; which code will be thrown away next month, and which will be maintained for years to come. You can, however, control your allocations: Like a stock trader balancing her portfolio, you cannot be certain which investments will pay off, and which will be losses, but you can bound your losses by limiting the time you spend on any one task. Diversify your portfolio of contributions. Plant many seeds, then see which take root, and which are not worth watering.
For ideas on managing uncertainty, so that you know (especially at a startup) where to invest your time, take a look at the book The Lean Startup by Eric Ries. To see how a larger team can stay on the same page as it develops a big project over a period of years, read The Mythical Man-Month by Fred Brooks. (The Mythical Man-Month is a great read, even if books on professional development aren't usually your thing.)