

Ask HN: What do you waste too much time on as a developer? - lukeqsee


======
danohuiginn
Sysadmin. Not because it's time-consuming (though it can be), but because of
the context-switching involved when most of your work is development. Sysadmin
requires multitasking, starting jobs to run and coming back an hour later to
check on them, keeping an eye on your monitoring systems, etc. Programming
requires total concentration on one thing. The two ways of working don't mix
well.

~~~
Lewisham
I can buy sysadmin as being a large sink. I personally enjoy sysadmin (nothing
like a clean box!), so I tend to do it as a hobby, but when you're in a
startup, I'm certain it is just a frustration.

That being said, I'm presuming you're doing sysadmin under a *nix environment.
Sysadmining a Windows box is just brutal.

------
Lewisham
Email.

Email is the bane of my existence. Most of the proposed email deluge handling
systems advocate dealing with email for set time periods. This is fine, as a
_personal_ thing, but my time with email is mostly spent spinning wheels
because I am waiting for a reply to something I need. I don't want those
people dealing with email in set time periods, I want the information _now_! I
want _their_ workflow to be severely impacted :)

Which then leads to the necessity of phone calls, which is an even greater
time sink.

I ended up resolving to just walk to the person's office if its < 15 minutes
and treat it as a keyboard break. Now I'm back in grad school and work from
home a lot, so I'm back to waiting for emails again.

~~~
banuelios
That's one of the reasons Skype replaced Email as our primary means to
communicate.

------
knieveltech
Reading articles on hacker news. Seriously.

~~~
mathgladiator
And reading the comments...

~~~
vijaydev
and upvoting them...

~~~
fuelfive
and writing deeply nested replies...

~~~
cvg
Ack! I think I still have some code to write...

~~~
sr3d
context switching after reading HN and returning to code

------
donohoe
Meetings.

In the end I just stopped going. For the most part I was one of many people
invited who didn't truly need to be there. Sometimes people will turn up at my
desk 5 min prior to remind me in which case I figure I should go - and usually
that's a nice indicator.

I still go to ones I need to go, but I've gotten better about asking at the
very beginning of what the purpose of the meeting is and what we need to
resolve in the next 30 or 60 minutes.

It's a big help and saved me 2 days per week aprox.

I also stopped checking voicemail about 2 years ago and don't answer the
phone. That helped a small bit and people know to reach me on IM or email.

------
_delirium
Probably architecting and choosing between options, though it's not _all_
wasted. Most of the stuff I do can probably be best done by doing an ugly
first implementation, throwing it away and replacing it with a better one, and
then abstracting out some nice modules and interfaces, and iterating from
there. But my instinct is to analyze the problem up front, decide what the
_right_ interfaces are, which the _right_ third-party libraries (or even
languages) are, and before you know it, I've spent a whole day reading about
Clojure's concurrency primitives, or pros and cons of different OO patterns,
or comparisons of Library X and similar-sounding Library Y. The worst is when
the available information isn't that good, so all I've gotten out of my hours
of reading is, "huh, libraries X and Y sound pretty similar, and I still don't
really know which is better for my purposes; I'll just have to pick one and
see".

It does occasionally lead to an epiphany of the "aha, my problem is exactly
[this]!" variety, so sometimes it works.

------
devinj
Code. My projects need more documentation, always, but I keep writing new
things and not adding new documentation until after I've stopped working on it
for 3 months, try to get back in, and entirely forget what I was going for in
the design.

------
kineticac
I'm surprised nobody has mentioned developing and hacking the crap out of view
code in order to support Internet Explorer 6. It's a waste of time. People who
use IE6 already see the internet as a horrible experience, so trying to make
your own product or webpage work is just a big waste of time.

Sysadmin work is also really horrible, though I would say it's unneeded these
days with the help of services like Heroku.

------
bigsassy
Coming up with names for classes and variables :-)

------
mcantor
Sifting through someone else's code or half-assed documentation to figure out
how to use a third-party library.

------
barrydahlberg
My day job.

------
ams6110
Meetings

------
sfalbo
Tracking down information from others...

~~~
MrFoof
Documentation is one of the things that everyone wants, but no one provides
themselves. Nearly every organization suffers this. "Read the code" is not a
good answer when time is a factor. I write obnoxious amounts of documentation
as I write systems. I used to get called out for it, until I would be out, a
problem would occur, and then someone else was easily able to take care of it
by reading said documentation.

The main time waster for me is being told to "maintain" a system instead of
refactoring it. A great example is a recent project I've finished up. Years
were spent trying to create bandaids for major design deficiencies. They never
solved the problem since there were fundamental design flaws. It was slow. It
produced only somewhat useful results. It required lots of time and effort for
maintenance.

After much hemming and hawing (and the reality that the system hadn't
delivered its expected value after 3 years) I was given the green light to
rewrite it. I spent a month validating the design, and 2 1/2 months rewriting
it and putting it into production alongside the existing parallel system. The
new old system will be turned off in 2 or 3 weeks.

Benefits?

* It produces correct results for downstream apps. This item alone made the effort worthwhile. Everything else is simply gravy.

* As a result of the first item, we now have reverse engineered another vendor's feed with uncanny accurcy. We can now "front-run" them, reducing our latency to act in the market. We can also cancel a subscription that has a $200,000/yr price tag. We can also decommission that system freeing up hardware.

* The time is takes to load new data from the vendor was reduced from 50 minutes to 4. It now scales perfectly linear with new data volume, instead of ever-increasing over time. It can also still be faster (down to ~3 minutes), but those improvements need to be made by another group.

* Since its faster, and has very little overhead, the server has gone from burdened to idle. We can now have other systems take advantage of this great hardware (16-core, 64GB of memory, FusionIO scratch space, very fast SAN hardware).

* The storage footprint of the data warehouse was reduced by 50%.

* On top of the storage reduction, replication to our disaster recovery site was reduced by an additional 70% (on top of the initial 50% from reduced data volume) because of how the data is structured.

* Source code reduction? 85% fewer lines. It is now ruthlessly simple.

* Maintenance? It now auto-recovers. Untrained operations staff just perform 2 automated steps to recover from 99% of problems that we expect to occur in production.

~~~
pizzaman
i hope you're getting a good bonus for that!

------
antichaos
Google Reader and HN.

------
pizzaman
youtube

------
nato1138
I never got into vim plugins that work well with my typical dev setup... so I
am constantly closing and opening files deep in an hierarchy ie. :spl
app/to/stupid/file.foo... It take a second to do -- but I do it _all_ the
time. I bet it adds up to be a lot.

~~~
cma
A fuzzy finder can solve this, but you can also take out 90% of the pain with:

    
    
        :set autochdir
    

It will auto-change dirs to the immediate parent directory of each file you
edit.

