Ask HN: How do I become more productive as a programmer? | Hacker News Reader

Ask HN: How do I become more productive as a programmer?

24 pointsPopeOfNope25 comments

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?

View on HN

You should introduce your so-called 'management' to the concept of technical debt. Churning out code fast is only useful if you're going to throw away the code completely in a few days. If the code needs to live longer, initial speed becomes unimportant and maintainability takes over.

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.

This is a good point. I experienced something like this years ago when I was at a company where I was one of the older employees (not even 30 yet!) To my knowledge, nobody complained about my productivity during the main development cycle, but I never felt like I was keeping up with the younger rock stars (who really were amazing).

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).

So true.

My wife is an Economist for the state and spent some time as a Regional Analyst giving presentations to job seekers and those who help them. She said that the biggest hurdle an aging programmer seems to have is an inability to learn new languages and standards, because they feel that what they know is "good enough"

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.

> Are you learning?

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!

My wife occasionally asks me, "What do you need to learn now in order to have a job in five years?" My current answer is "Android", but that may not be the correct answer for your situation.

Stop overthinking. When you were young, you didn't know anything, so you had no choice but to start coding. You get older, you have seen a hundred different ways, and analysis paralysis becomes a crutch. Stop over thinking, start doing, even if you gotta cowboy code it. Use a language with a nice REPL, Lisp, Prolog, Python, even something like psysh for PHP, explore your ideas. Then when you are done experimenting, code fast. Refactor fast.

Some guiding principles I go by

* Ship it. Don't over engineer.

* Best code is code you don't have to write.

  Don't equate programmer productivity with lines of code.
  
  This means spend more time thinking.

* Productivity is relative. It depends on the project.

  In startups it's shipping working code. In large organizations, it's shipping maintainable code.

  Sometimes you might spend more time doing something correctly that might not be immediately productive but down the road, it saves time in maintanance.

* 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.

You're thinking more deeply, and therefore less quickly. You need to move on to harder problems. That's where the value of your experience will show up.

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

> You need to move on to harder problems.

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!

Ultimately you will need to either work for yourself or have an open-source project on the side that you work on at your natural speed without pressure from others. As others here have noted, technical debt is not something most managers are concerned about, because it's a future cost, and they are judged on shipping code.

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.

the crazy Wall Street valuations of technically indebted companies like Facebook

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.

Is there a reason you prefer Relax NG over XML schema for the purpose of writing data structures?

You've probably already read this, but it's a very elegant algorithm for validating Relax NG. http://www.thaiopensource.com/relaxng/derivative.html

Thanks for the response. I came to a similar conclusion about eventually having to work for myself, but keep putting it off. It sounds like I need to buckle down and build something.

I've never even heard of relax NG. These days I prefer json to xml, but I'll look into it anyway. :)

Why do you have that perception of yourself? Are you sure that management perceives you that way? It sounds suspiciously like the kind of paranoia that would come from working in a toxically competitive, non-collaborative environment.

I have that perception because I'm currently on my company's version of performance probation. In my company, the engineering manager sets the estimate and the programmers are expected to at least come close. In my case, the time it takes me to complete a task is around 5x greater than the original estimate.

" But, all management sees is that it takes me longer to finish an equivalent task than the rest of my peers."

This 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.

Indeed; lots of good stuff here, but for the immediate decision, the OP needs to find some part of the company's work that demands higher quality, accept doing lower quality work fast and learn how to do that (yuk), or find another company, or perhaps a subfield, where quality is rewarded.

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.

Pen and paper. I find that writing down ideas related to a piece of code I'm currently working on, or writing down the next tasks I have to work on helps me stay focused and productive throughout the day. If I get stuck on something, I'll also brainstorm on pen and paper.

My solution isn't perfect, but its helped tremendously. It also serves as an ever-present todo list if my mind wanders a little.

This is a great suggestion and one that I'm already doing. I find it doesn't speed me up, it slows me down. It does make for better code, though.

Maybe, you've noticed that the actually technologies just get new names every few years ;)

Part of being a more efficient programmer is writing tests. If your company isn't writing tests, they should be.

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.

I've done TDD at a few places now and I've never seen it speed up development time. It has always added overhead in terms of time and complexity, to the point where it's almost always dropped after the first deadline crunch.

Anyway, I'm not a big fan of any programming methodology. The best solution to a problem is never one size fits all.

Use vim

I do use vim. :)

Reply on news.ycombinator.com