Ask HN: How productive are you? | Hacker News Reader

Ask HN: How productive are you?

15 pointsfrickskit16 comments

I'm a programmer at a trading firm, and I am interested in how productive or unproductive people in this industry are. I know it's hard to quantify productivity and even more so comparing across industries and projects, but some anecdotes could help paint the picture.

Do you sometimes spend a whole day working on a supposedly "simple" bug fix? Do you spend most of the day in meetings? How many hours do you work? How has this changed over your career?

I know productivity is not measured in hours.

View on HN

This is something I have noticed a lot over the last three years.

I started at a sequencing centre to build the database for them from scratch. I decided to give Django a try. That took up a bit more time for the first couple of months as I was learning the concepts. But once I started to get to know it (and realized that a lot of the problems I was coding had already been implemented as part of the framework - a lot better than I had done), my productivity rocketed. The admin interface gave me 3/4 of what we were looking for without much effort at all.

I was in an office with another girl, so basically if we were talking to each other that was the only interruptions.

Three years later. We are four of us crammed into the same office. Management regularly comes down to discuss things with one person (despite having a big office upstairs for that sort of thing). Makes concentrating on a learning new feature difficult. The database is now central to running of the organization, so I am constantly bugged to fix excel upload errors (parsing excels was supposed to be a temporary solution, until I got a chance to implement something better - now it has become a chicken and egg situation - I don't get the time to code anything better, as I am constantly interrupted by trivial errors that should have been eliminated by building a proper interface ages ago).

I know form experience now that I can code a new, moderatly complex web view to return some results from the database, highlight problems etc in maybe three or four days, if I am uninterrupted. Now try doing that with constant "can you see what my excel errors is?" (honestly - its says in the big red error message - "there is nothing in the database matching what you have entered"). Writing anything that takes more than a day when you are constantly context switching easily makes me a quarter of the productivity of focusing on one task.

So I have see myself having a big drop in productivity mainly caused by poor management decisions in my opinion. As long as its not causing them any direct pain, then they are happy with the status quo.

This is actually pretty relevant to me too. I have software trading in real time, while at the same time I'm developing new software. Every time a fill comes in I evaluate it and am always half-paranoid that I'll discover a bug in why I traded that. Makes it hard for me to focus fully on programming.

I have similar experiences. Sometimes, as part of a fix for an investigation like this that I'm tasked with, I simply take the three days and build the actual correct solution. Or I build part of it, use it to partially automate what I'm investigating, and then continue to build on it next time a similar investigation comes up. Once I'm done with the better solution, I present it to the people who would use it, and transition them towards using that.

It's not always possible depending on the type of organization. A lot of managers are offended that you would work on something they didn't ask you to work on, even though they would never think to ask you to work on the thing, and even though the thing you work on pays for itself over a short period of time.

Other times I just say fuck it. If you want to pay me to do the same investigation over and over, I'll mentally check out while I collect my paycheck and spend my extra time teaching myself skills for my next job.

+1 on your last sentence. If management can't spare anything to treat you better then why bother going the extra mile? Gear up for your next (better) job.

Productivity can't be measured by hours because a single thought can change the course of a company, or a life... but that thought can take months or years to develop in order to be "thought."

For example, there is a running joke here on Hacker News about HN being a time-sink. I disagree. Some of the comments here have altered my thinking about startups. A single comment can change the course of a life.

Paul Graham's "Beating the Averages" has influenced how many programmers to pick up Lisp? One essay can change a life, or a company.

Productivity does not accumulate with X hours. It grows in starts, jumps, leaps and crawls. For those who work with their brains, accomplishment is not lines of code written, or the number of pages in your business plan.

Productivity is a result of thought, and thought often comes through a lost art called "leisure."

I would love to be able to wake up on a morning, fill my day with inspiration and have solutions come to me immediately as I worked and do that for a solid 8 hours and crank out thousands of lines a code every day. Isn't ever going to happen.

Today I wrote 3 lines, they were really important lines, they took me 4 hours. 3 hours and 59 minutes to work out what had to happen, why and how and 1 minute to type it out. Then I was done for the day. Was it a productive day? Depends how you look at it really, I could have spent 8 hours writing reams of code to achieve the same result. I measure how productive today was based on how many lines of code I didn't write.

> Today I wrote 3 lines, they were really important lines, they took me 4 hours.

Haskell? :)

Haskell is like a fine wine. It is meant to be sipped.

Productivity can be measured in raw output but it can also be very subjective, it is easy to fall into the trap of thinking (or having your boss tell) you have not been productive during a day when actually you have.

Productivity needs to be measured over weeks or better months. An hour, a morning or a day is too small timeframe to access how productive you have been.

I write down what has been improved, 5 mins at the end of the day. Code I have developed, customers I have helped, sales I have made. It's a nice list to look at later. Easy to forget what you have improved. Writing down distractions also helps me to look how to eliminate them.

I'd say I was the most productive when it took me eight hours to write a seven line shell script. That replaced 2,650 lines of C.

The previous programming team had written a data transfer program with its own implementation of ftp. I just used the one which was already on the computer.

It took me a while because I had to read the Unix source code to find out if my program would work. In the days before Google, and even the World Wide Web, I used a combination of Gopher and WAIS to find a publically available copy. That was difficult as it had been released only to universities with a licence saying it must be kept hidden.

I work for a software solution consultancy. I tend to see productivity come and go in waves.

New projects => new enthusiasm => more productivity.

Towards the end of projects, and projects that require support and the odd feature addition tend to have much lower productivity.

Same here, I'll find myself working weekends when I just get started, and leaving early when I'm nearing the end... tricky to change since I'm just not all that interested by the end.

This is spot on. When I started writing the application I'm working on, it was as though I could divine new features overnight with little effort. Now, much of my energy goes to making sure I don't screw myself over with bad design decisions, fixing bugs, and answering questions about the software. I find that it is hard to write any code on some days. I'm glad to see this is common.

We often see a large "setup" sprint 0 set of tasks when kicking off a project. That being said, we are working in the MS environment using Visual Studio and Team Foundation Server.

The setting up of the initial architecture, including ops tasks such as setting up the build / test servers is a painfully long process. I'd love to find a way to speed this up. Boilerplate setup would be extremely useful.

My productivity tips:

- to do lists and pomodoro technique

- automate everything what can be automated

- delegate everything what can be delegated

Productivity can, at least partially, be measured in hours.

For example, turnover/hours worked, GDP per capita/hours worked, etc.

right, you definitely need the denominator there, that's true.

Reply on news.ycombinator.com