6 ms·
Ask HN: What do you waste too much time on as a developer?
- sfalbo 16y agoTracking down information from others...
- MrFoof 16y agoDocumentation 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 16y agoi hope you're getting a good bonus for that!
- knieveltech 16y agoReading articles on hacker news. Seriously.
- mathgladiator 16y agoAnd reading the comments...
- danohuiginn 16y agoSysadmin. 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 16y agoI 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.
- nato1138 16y agoI 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.
- ams6110 16y agoMeetings
- Lewisham 16y agoEmail. 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.
- devinj 16y agoCode. 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.
- mcantor 16y agoSifting through someone else's code or half-assed documentation to figure out how to use a third-party library.
- bigsassy 16y agoComing up with names for classes and variables :-)
- pizzaman 16y agoyoutube
- donohoe 16y agoMeetings. 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.
- antichaos 16y agoGoogle Reader and HN.
- _delirium 16y agoProbably 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.
- barrydahlberg 16y agoMy day job.
- kineticac 16y agoI'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.