Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Welcome to experience. Have you ever tried walking along the outline of a balance beam drawn on the floor? Jumping along it? Now move the balance beam 1' off the ground, still easy? try 5' and take away the mats. The difference between walking the outline and walking the beam is that you can 'see' the consequences of failure and you know they hurt.

Not surprisingly this happens in engineering as well. You start "just trying to get it done" and when you didn't know better you just wrote it. But now that you know better, perhaps you've been bitten by an unchecked return value or a fixed length array, so now you reflexively look for those things, you fix them, you refactor them. This slows you down, and your fresh graduate peers start thinking "the old guy is slowin' down."

The only way I've found to move past this to let go of the responsibility when your manager asks you to. The conversation you have is "Boss, I can crank this out quickly but the faster its written the more likely it will have some future problem in it." then write that into the comment "Boss asked me to hack this out, said he would take responsibility date - time" and then just write it and move on. Later if it screws up you don't worry about it.

But you can't just go all irresponsible on them, you also need to think about the kinds of things your doing and step up your game in terms of what some folks called 'design patterns' make an effort to capture the way you write the things you write all the time and train your fingers to spit out an 'ok' version from the start.

Good luck.



> The conversation you have is "Boss, I can crank this out quickly but the faster its written the more likely it will have some future problem in it."

Not entirely sure if this is satire or not but it's a genuine conversation that I've had with a few clients.

I call it "the spectrum of quality" conversation. I can write beautiful unit tested code that will not explode unexpectedly at 3am on a Sunday several years later...but it won't be (relatively) quick to get there.

Alternatively, I can rush through something that will have to be rewritten later and it'll only take me a few hours. Part of me dies writing that type of code but there's a time and a place for it.

You want to hit the afterburner? No problem, but there are consequences.


Technical debt. There's a time and place for it, but as financial debt you'll have to pay it back, with interests.

The best thing about the term, is that not technical people know and understand how debt works, so they can make a more or less informed decision and don't get that much surprised in the future when something need a big refactoring :)


That is exactly right. One the most interesting things I heard from a departing Google engineer was that he was declaring 'technical bankruptcy.' He was so fed up with hacking things together to make them work and not doing them 'right' that he just couldn't take it any more. So much of the way we work as engineers has analogs in finance that it stuns me some times.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: