Ask HN: How do I become more productive as a programmer?
I'm a mediocre programmer in my early 30's with 10+ years of web development under my belt and a senior title. When I was younger and more junior, my rate of development was never a problem. As I get older, I've noticed that the rate at which I spit out code has slowed down. I think through tasks a bit more thoroughly now and do more prep work before coding. I believe the solutions I come up with are better, faster and easier to maintain than anything I came up with in my youth. But, all management sees is that it takes me longer to finish an equivalent task than the rest of my peers.
Is this something I need to work on to be competitive in my field? Or is this a case of companies trying to squeeze more value out of their employees? And if I do need to increase my rate of development, what's the best way to do that?
27 comments
[ 3.5 ms ] story [ 92.5 ms ] threadThis is your only problem. If your manager cannot understand that quality is better than quantity, then you may want to entertain the idea of changing companies.
This appears to be one of the reasons grey hair is generally respected in embedded work (not in Detroit, though), the cost of low quality there can be very very high.
Basically 'the faster you are upfront, the slower you'll be down the road'.
There's a nice saying that goes something like 'a 10x programmer is called so because it takes 10 programmers to clean up his mess after he left the company for his next rock-star gig'. Mostly true.
Then the product development cycle was near the end and testing was underway. At one point during a meeting someone actually complained that I had no bugs in the tracking system assigned to me while most developers had hundreds. My boss actually spoke up and said "I've noticed that too, but it's because nobody is finding errors in his code."
I spent a few months helping other developers find and fix their bugs.
I think if you invest in quality, in the long term other people will see and value it (in most environments).
As I move into my mid-40's, I am writing software I never dreamed possible 10 years ago, but the speed is much slower, sometimes a month will pass with only a couple lines of production code being written, then after a concept gels, everything comes together fairly quickly. I would have been fired long ago working for someone else at that speed.
Hacking culture and the crazy Wall Street valuations of technically indebted companies like Facebook have distorted where people see value in software, and what they consider a normal development cycle, but don't pay attention to that - envision perfect software and work every day to improve your skills, eventually you will close the gap and you will find yourself to be not mediocre any longer.
On a practical level, I gained a lot of productivity by learning Relax NG - formulating your data structures and relationships concretely before beginning to write code has saved innumerable wrong turns and helped avoid misunderstandings with my clients.
But didn't Facebook transition out of that mode of heavy technical debt? And was it so bad to begin with, e.g. the classic story here is of the competition with Friendster, where the latter decisively lost because the board was off in the clouds thinking deals and was simply not interested in the fact that logging in and doing basic things kept taking longer and longer, eventually minutes as I recall.
You've probably already read this, but it's a very elegant algorithm for validating Relax NG. http://www.thaiopensource.com/relaxng/derivative.html
I've never even heard of relax NG. These days I prefer json to xml, but I'll look into it anyway. :)
These are the people without jobs.
Her perspective is that so long as you are willing to embrace change, you will always continue to be employable in a changing market.
Now, here's my perspective:
Are you learning?
If you aren't continuing to evolve as a programmer, that is when you need to worry. So long as you are tackling new challenges, learning how to write the same things you used to more efficiently and better documented, and keeping up with the changes in your languages, you will be alright.
If you want to increase your rate of development, I highly suggest building and maintaining a collection of libraries and snippets that you commonly use to help facilitate faster deployments. It may take longer to condense things into classes and libraries at first, but soon you will be able to rip out new features faster than ever before.
Yes, but learning what? I keep on top of the latest in all things Javascript, which is one of the reasons I have the job I currently have.
> If you want to increase your rate of development, I highly suggest building and maintaining a collection of libraries and snippets that you commonly use to help facilitate faster deployments. It may take longer to condense things into classes and libraries at first, but soon you will be able to rip out new features faster than ever before.
That's a good idea. I should put together my own personal library, or maybe my own little code generator. Thanks!
This allow you to adopt the methodology of writing tests, passing tests, then refactoring. This allows you to spend less time planning and more time writing working code.
Anyway, I'm not a big fan of any programming methodology. The best solution to a problem is never one size fits all.
My solution isn't perfect, but its helped tremendously. It also serves as an ever-present todo list if my mind wanders a little.
It gets harder to find those spots, though. I've seen a bunch of job posts that say "senior developer, 5-7 years experience". You've got 10. You're past what most people think of as "senior developer".
You might consider going to your manager, explaining your view of this situation, and ask to be put on the hardest problem he has. If he/she bites, that's your chance to shine. If not, it's probably your cue to start hunting for someplace where you can shine...
That is a thought that hadn't occurred to me, but it makes sense. If I'm not tackling problems that a kid straight out of college can't do faster (sloppier, but faster), then why are they paying me more, right? Now to find out what the hardest problem is the company is and try to tackle it. I'm already on thin ice. I might as well dance.
Thank you!
* Ship it. Don't over engineer.
* Best code is code you don't have to write.
* Productivity is relative. It depends on the project. * Programming is about delivering business value. No one cares how awesome your code is. It has to translate to business value and communicating that value.* Ship it. Don't over engineer.
* Best code is code you don't have to write.
* Productivity is relative. It depends on the project. * Programming is about delivering business value. No one cares how awesome your code is. It has to translate to business value and communicating that value.