
Ask HN: How do I become more productive as a programmer? - PopeOfNope
I&#x27;m a mediocre programmer in my early 30&#x27;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&#x27;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.<p>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&#x27;s the best way to do that?
======
flohofwoe
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.

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

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

~~~
PopeOfNope
> 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!

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

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

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

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

~~~
PopeOfNope
> 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!

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

~~~
hga
_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.

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

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

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

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

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

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

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

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

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

------
motyar
Use vim

~~~
PopeOfNope
I do use vim. :)

