Give A Damn | Hacker News Reader

Give A Damn

clayallsopp.com

132 points10char37 comments

I have different problem - I just can't code like The Kid anymore. I know I could in the past, I have the code to confirm this. Not anymore, I'm not able to.

And often I'm required to. My boss says: "just hack it quickly" or "it's one-shot script, just write it" and wants it done in an hour or so. And I can't do this.

I don't even know why I can't. I tried many times to "just code" and there's something in my mind that seems to be opposed to this. This "something" refuses to use unknown or not fully understood tools. It refuses to let ugly line of code be. I feel like I'm refactoring my "one-shot" scripts reflexively, without me noticing. And the worst thing is I do it continuosly - not when the script is finished and somehow works, but during writing it for the first time. I know exactly when was the last time I wrote more than twenty (Python) lines of code without breaking the code into functions and classes, caring about names and comments: in 2004. Tests came later, but now they are a reflex too.

And now what my boss wants done in an hour I write in three or four. Then he's getting angry and tells me to go clean and document some code or to implement something else, and I do, and it more often than not works and - I hear - could even be a pleasure to read. But then, few days later, he wants me to quickly convert something or export something or something like that and I just can't do it, unless I have previous script ready. Then he's angry again...

TL;DR - giving a damn is certainly a good thing, sometimes, but taken to the extreme can disturb your career.

If you're a chef and you're consistantly asked to short order cook then change kitchens.

Or, change your utensils and embrace being a short order cook.

That's a pretty interesting situation. I certainly don't think there's any "something" blocking you, I'd guess it's more of a vague feeling of caution that you're clinging to because you can't quite understand it. It's easy to get into these traps when it's something very important (like your job).

There are a few things you can try. You can create a personal project to explore the depths of "not refactoring", in hopes that you'll get used to it. You could also just try getting faster at your newer technique: writing code and refactoring in an hour instead of 3 (learning your tools like a master helps with this).

Your "sudden change" probably wasn't so sudden, but rather your experience with hitting the limitations of writing shitty code. Now you want to avoid those pitfalls in the future, but your boss doesn't seem to understand.

There's also plenty of places for you to go still, if none of the above works for you.

Edit: Creating a checklist of "the smallest chunk of work" can help you keep moving rather than getting stuck in tweakfinity.

A few suggestions based on my experience (I have the same problem sometimes...):

- "get it working and keep it working": get the minimal possible functionality working (outputting some result, even if there's utterly no error handling, input is ignored, all of the requisite services are stubs and any actual processing is faked), and make sure you keep it working -- if some refactoring is going to take more than an hour or two, plan it differently. This helps you get really quickly to a proof-of-concept (with TODOs everywhere in the code), and stops you from shredding it to "do it right" because that would break it.

- keep a list of your ideas of how to do it correctly, in a separate file. Yes, for the moment we're dropping the input directly into a SQL query and returning the result directly wrapped in a <pre> tag; for the real product we'll need parametrized queries, a dynamically loading JS table (to research), etc. etc.

- stay offline. Do not download libraries or frameworks, do not research the best way to do X, do not research the problem domain or look for open source projects that do similar things but are huge and will suck up your entire afternoon when you could have just hacked out a completely unreuseable, inflexible, one-time fix for this particular problem in an hour. Research is fun, it's interesting, and it's a way to avoid actually doing what you need to do -- half-assed work. If you really need to look something up, put it on a list, and give yourself 10 minutes to research everything on the list in a few hours.

Good luck!

Great advice, both from you and grandparent. First, I wanted to say that my boss is a programmer himself, much better than I am, and he understands the value of good code very well. But he's also a bussinesperson and knows when the product is much more important than the code - I trust him on this. At least consciously. It's really not his fault at all.

---

> You can create a personal project to explore the depths of "not refactoring", in hopes that you'll get used to it.

I can't. I mean - I do program in my spare time and have side projects, but if anything it worsens the situation: I have more time and no deadline, so I just tinker with the code until I'm satisfied. And I am satisfied, it's not like I don't know what "good enough" means, just that in personal projects that level of "good" is even higher, because I'm the one who sets it.

> You could also just try getting faster at your newer technique: writing code and refactoring in an hour instead of 3 (learning your tools like a master helps with this)

This is exactly what I'm trying to do - but it's a workaround at best, not a solution to the problem.

> rather your experience with hitting the limitations of writing shitty code

That's true - around that time I was part of a team that developed CRM system in PHP. It was meant to be 3-4 months project but in the end it was a year long nightmare of rewrites and feeling guilty for everything. I never did any postmortem or proper analysis of what went wrong (everything) and maybe that's why my attitude changed. I wonder if it's too late now?

---

> "get it working and keep it working"

This is a way I work most of the time. And refactoring I do and am talking about is always much quicker than an hour - I do it in very small chunks, one function or class at a time, not breaking the code. It's just that these very small refactorings pile up and in effect I have a nice script, which is documented and properly structured, and which took twice as long to write than it should.

> keep a list of your ideas of how to do it correctly, in a separate file

I do this with larger ideas. It's not that. Rather, I can't force myself to drop the input directly in the SQL using string formatting. I know I did it in PHP years ago and it burned me so hard I won't do it again. Willingly, at least.

> stay offline. Do not download libraries or frameworks, do not research the best way to do X... > if you really need to look something up, put it on a list, and give yourself 10 minutes to research everything on the list in a few hours

This seems to be exactly what I need to do. It never occurred to me, but when I think about it I see that looking for "better" implementation in libraries eats large chunks of my time. And these implementations aren't even that good... Combined with mastery of tools, I think it can work. Thanks, I get the feeling that there is hope for me :)

> It's just that these very small refactorings pile up and in effect I have a nice script, which is documented and properly structured, and which took twice as long to write than it should.

Ah ha... one solution, then, may be to force yourself to stop when it's only just barely working, instead of continuing on refactoring. :)

>This "something" refuses to use unknown or not fully understood tools. It refuses to let ugly line of code be.

It's called being a perfectionist.

There's one more aspect at play here too:

If you're brash and "break things" and overall the situation turn out for the worst, if you're a kid, people will tutt and mutter and aww shucks who should have been supervising those rough edges on the young whipper snapper.

If you make the exactly the same mistake in a more senior positions / with grey hair, people will bring your qualifications into question - and I suspect those with political interests will try and leverage the failure against you.

I've felt the same way for a long time. At length I've finally decided that the fear comes from simply having been burned one too many times by that "one-shot script" that I was forced to "just hack quickly" becoming the freaking cornerstone of some business process and then weighing me down like a millstone around my neck for years afterwards.

I still get calls from a company I worked at more than a decade ago from people I've never even heard of over something I "just hacked together" one idle weekend as a demonstration of what was possible. Of course, its been hacked and bodged by others for a decade now so I don't know any more than they do at this point. It doesn't matter. My number is company lore and I'm their Gandalf.

Its just not worth it. These days, I do it well, or not at all.

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.

A boss who tells you to crank something out in a hour won't remember (or care) about that detail in 6 months when you need to tweak that code. It'll just be your fault for writing bad code. Some clients do this kind of thing as well. They ask for a Cadillac, but can only afford the economy version. But - at the end of the project they'll still be expecting all of the Cadillac features and everybody will forget.

I can sympathize about bosses who are angry that things don't get done quickly enough, but there has to be a balance. If I was continually running into this I'd probably look for a new job where quality was encouraged.

I do know what you mean, I'm at that stage where I start to care more about process more than anything. It's not about getting the job done - it's about getting the job done efficiently and with as few mis-steps as possible.

It's easy to so get wrapped up in the process that you don't like to introduce risk of experimentation.

On the other hand, I'm reminded of this passage from HPMoR:

"But Father had once told her that the trouble with passing up opportunities was that it was habit-forming. If you told yourself you were waiting for a better opportunity next time, why, next time you'd probably tell yourself the same thing. Father had said that most people spent their whole lives waiting for an opportunity that was good enough, and then they died. Father had said that while seizing opportunities would mean that all sorts of things went wrong, it wasn't nearly as bad as being a hopeless lump. Father had said that after she got into the habit of seizing opportunities, then it was time to start being picky about them."

Or, in context: You can't skip directly to writing quality code. First, you have to get used to writing code, and to do that, you have to write a lot of it. You have to get used to getting things done. Only after you have a good grasp of getting things done, of seeing a project to completion, should you start worrying about code quality.

I have a lot of unfinished projects, and a lot of smaller projects that I have finished. I'm sure all of us do. But once, I decided not to worry so much and just start writing, and I started and shipped an incredibly ambitious project. It wasn't my best code, but it taught me a lot about not sitting at a blank screen trying to plan everything to be perfect before starting.

Totally agree, and this applies to almost every creative endeavor I can think of. If you want to write a book, throw words on a page. If you want to start a company, launch an MVP and iterate fast. All things being equal, doing is better than not doing, and doing well is better than doing poorly.

If you're interested in this topic w.r.t software engineering, check out Michael Lopp's article in The Magazine about Stables and Volatiles[1]. Really good piece on how companies are composed of and need both Volatiles like The Kid who move fast and innovate, and Stables who clean up the mess and move the company towards profitability.

[1]: http://the-magazine.org/1/stables-and-volatiles

Another term I like to use is analysis paralysis - basically spending all of your time preparing to do something, but getting bogged down in the preparation instead of the actual goal.

Kent Beck, the guy who created Extreme Programming, Test Driven Development, and the first Unit Test Library ever, made a very similar point about this a few years ago, in his "The Flight of the Startup"[1]

In the taxi phase, breadth, speed, and, above all, cost of experimentation is the key. Try out ideas related to lots of different needs. Precision of feedback during the taxi phase is less important than trying out lots of different kind of ideas. The risk during the taxi phase is that you won’t find a genuine need. Address this by reducing the cost of experiments and running many of them.

After working for a while for Facebook (the move fast and break things company) he described how deployment speed dramatically affects how you work on his "Software G Forces: The Effects of Acceleration"[2].

So, it is not a secret that discovering "something people want" is more important than working code[4], because failure if the great equalizer of code: all good code and all bad code is equally thrown away[5].

[1] http://www.threeriversinstitute.org/blog/?p=251

[2] http://www.youtube.com/watch?v=KIkUWG5ACFY which was seconded by Mary Poppendiek on her "How Cadence Predicts Process"[3]

[3] http://www.leanessays.com/2011/07/how-cadence-determines-pro...

[4] http://swik.net/Eclipse/Planet+Eclipse/Julius+Shaw:+Kent+Bec...

[5] http://www.universalsubtitles.org/en/videos/6FfAAXK00nWB/en/...

I'm gonna go out on a limb and say that this "kid" was not utilized correctly.

He had a valuable "1 in a million" skill and instead of finding a way leverage that skill in a new and innovative way the team pigeon holed him into a vanilla software engineer role. Perhaps he should have been responsible for building alpha releases for new customer features, understanding that the more detail-oriented software engineers would come in afterward and make the code production ready.

I see these two types in my job every day. One type can put something amazingly valuable out there in no time flat. The other type is meticulously detailed oriented and can perceive every possible permutation of a use case and ensure that the system is coded to handle them. Unfortunately the streams rarely cross, however we expect both types to do the same job due to our close minded view on roles and responsibilities.

In short, possibly, it was not the kid who did not "Give a Damn". Instead it was a rigid team who probably did not realize the value he could provide.

I strongly disagree with this sentiment. I see a lot of The Kid in myself in many ways, and I don't think that this individual is striving for some local optimization point which is going to make them extremely valuable, but is instead headed for mastery of his or her discipline. This might be presumptuous and even a little pretentious (apologies!), but I honestly don't think simply sticking to one side of the fence is the path to mastery.

Giving a damn is mostly about pursuing the end goal, which is pretty much just to ship incredibly high quality software which meets the demands that that piece of software is responsible for meeting.

Sometimes that means applying formal verification techniques or running nightly static analysis runs over your build. Other times, just enforcing code review is enough. On the other hand, in those insane, crucible, diffuse-bomb-with-paperclip moments, all you really have time for is the awful hack. There's a huge spectrum, but the point is context is everything.

Having experienced both ends of the scale spectrum, from the ivory tower of spaceflight software verification into the heart of a fast-paced, scrappy startup, I've only really realized how much more experience I need practicing software engineering principles to master my craft and profession.

> "Code is more than just a tool," I heard he said. "It's our craft. It's our muscle. And we need to train it. Chop wood. Carry water. Code."

I seem to hear this comparison between skilled manual labor (especially carpentry) and coding come up all the time. Yet I never hear writers or mathematicians making that comparison, and I rarely hear engineers or scientists in other disciplines make it. Maybe that's just because I listen more to programmers, but I think there's an actual difference, and I wonder why that is.

I also wonder whether or not there's any connection between writing better code and using "best practices" in all your google searches. I suspect not.

I can't tell if you're kidding or not...

Is your question, do writers and mathematicians also speak of elegance and aesthetic in their work? Do writers engage and practice free writing and side-projects to hone their skills, beside whatever they have to do to pay the bills?

Expand your world man, there's so much more out there.

Obviously elegance, aesthetics, and a desire for personal improvement are common factors between these professions. But I've spent a lot of time with writers, scientists, and mathematicians, and I've very rarely heard any of them analogize the process of improving at their work to carpentry or other skilled physical labor. But I hear this analogy from programmers all the time. Programmers talk about sharpening their saw instead of talking about writing another draft, even though to my mind programming is much closer to writing than it is to carpentry. That's what I wonder about.

Good writers will definitely tell you that practice makes perfect. That studying techniques and understanding the theory behind them will make you a better writer. Chop the wood, understand the different kinds of axes of different kinds of wood, perhaps even investigate how axes are made and what it takes to design one.

I think in science this is more invisible, because it is a natural part of the work. A scientist is naturally encouraged to scrutinize his knowledge and techniques to discover whether something can be improved, abstracted, done differently. However, I believe many would learn a lot from conscious attempts at that and especially in attempting to understand their process and way of working, instead of just their knowledge and tools.

As for engineering: there are often many procedures in place to make sure even an inexperienced engineer will produce solid work, often supervised and reviewed by more experienced ones. Practices that are also in place where good software engineering happens.

A lot of errors in the medical profession are attributable to the same mistakes as made in bad software engineering: a lone gunman mentality; a lack of communication and a lack of (following) procedures.

> I think there's an actual difference

I think so to. I think the reason is that in programming it is often quickly clear whether a product is deficient. When it is, it is usually clear what caused the deficiency. Often it is even attributable to (a) specific person(s). That has caused many programmers to be very conscious of how often they fail, which has caused them to be very introspective of how they work and how they can improve it.

Did anybody else end up with the voice of the narrator from the game "Bastion" in their head dictating this?

I have to say that my standard practice now is to write all my code twice. I write it the first time and just do "whatever" until it appears to work. Then go back and refector, add tests etc.

That second time I always find an astonishing number of bugs that I hadn't even considered.

It sounds like the all too common story of an inexperienced programmer being overwhelmed by technical debt[1] as their code grows larger and more complex. I'm sure it's a lesson that many programmers learn the hard way at some point in their careers (like I did).

[1] https://en.wikipedia.org/wiki/Technical_debt

I'm sure there's great programmers out there who can do things fast and well, so hopefully people won't be too quick to judge any fast workers because of this story. Tempting to think there's a quality cost to speed; could be the true cost is just a high salary.

Why not just work out the bugs in his redesign? You said he got it done extremely quickly. It didn't seem like he was presenting it as a final version, but rather as a demo. Instead you throw it all out? How long did the replacement version take to finish? How many people worked on it? Was it feature-complete and free of bugs?

This reads like someone getting their spirit broken.

In my experience, very quick and dirty code becomes correct faster with a rewrite than with incremental fixes.

There is a place in the ecosystem for programmers like this. There are times when a quick demo can have a huge effect on business prospects. The key is to understand that the whole thing needs to be recoded, by engineers who understand process and architecture. Then just put "the kid" on the next flashy demo.

I've had a side project on the go for 18 months now and am about to complete the third version. Each time I've started from scratch but the difference is each time I have cared just a bit more about the quality of the code and planned things more in advanced. It's still not perfect (by a long way at that) but if I had't just dived in on the first version I fear I would never have shipped the first version let alone be on to launching the 3 do over. This one, should (fingers crossed) be the one that I stick with, hopefully it is extendable and I actually cared about database design and normalisation this time around so that should work well for a while too.

I think that more experienced programmers can achieve the same results as The Kid. In a larger organization, you may have separation of programming roles so you may not have a 'Kid' at your disposal.

If you have a method for rapid prototyping or something which allows you to bash out a quick proof of concept. Sometimes management needs that as the visual impact goes a long way to getting projects approved.

So long as you then convey to others that there are bigger long term concerns and proper design to look into when making the full version you can take it from there.

At first I didn't like this story. It sounded too much as though The Kid got stuck in an inappropriate role.

But on reflection, it's more interesting. He was doing fine, then his situation changed. So he changed along with it.

I think that's what I like most about The Kid. He didn't quit, or blame anybody - he altered himself to better suit his environment.

My boss wants me to be The Kid. "The users won't know the difference!" Sure, you can just hack together everything and the users won't know, but at what cost in the long term?

Lesson 1) The Kid is unemployable Lesson 2) That's why The Kid is The Boss.

Be The Kid (or get a job).

Reply on news.ycombinator.com