8 ms·

Give A Damn

132 points by 10char 14y ago

afterburner 14y ago
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.
jiggy2011 14y ago
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.
danbmil99 14y ago
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.
Zarel 14y ago
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.
- 10char 14y ago
  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 http://the-magazine.org/1/stables-and-volatiles
- jakejake 14y ago
  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.
joelmichael 14y ago
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.
- Peaker 14y ago
  In my experience, very quick and dirty code becomes correct faster with a rewrite than with incremental fixes.
simonbarker87 14y ago
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.
jyap 14y ago
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.
greatzebu 14y ago
> "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.
- kwekly 14y ago
  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.
  - greatzebu 14y ago
    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.
- Confusion 14y ago
  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.
DanielRibeiro 14y ago
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 http://www.threeriversinstitute.org/blog/?p=251 [2] http://www.youtube.com/watch?v=KIkUWG5ACFY 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-process.html http://www.leanessays.com/2011/07/how-cadence-determines-pro... [4] http://swik.net/Eclipse/Planet+Eclipse/Julius+Shaw:+Kent+Beck+Revises+the+Agile+Manifesto+%28for+startups%29/d056n http://swik.net/Eclipse/Planet+Eclipse/Julius+Shaw:+Kent+Bec... [5] http://www.universalsubtitles.org/en/videos/6FfAAXK00nWB/en/182318/ http://www.universalsubtitles.org/en/videos/6FfAAXK00nWB/en/...
klibertp 14y ago
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.
- mcantelon 14y ago
  If you're a chef and you're consistantly asked to short order cook then change kitchens.
  - lrobb 14y ago
    Or, change your utensils and embrace being a short order cook.
- NinetyNine 14y ago
  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.
greenyoda 14y ago
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 https://en.wikipedia.org/wiki/Technical_debt
imechura 14y ago
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.
- mvanveen 14y ago
  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.
iopq 14y ago
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?
elliottkember 14y ago
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.
BungleBob 14y ago
Lesson 1) The Kid is unemployable Lesson 2) That's why The Kid is The Boss. Be The Kid (or get a job).

132 points by 10char 14y ago

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.

jiggy2011 14y ago

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.

danbmil99 14y ago

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.

Zarel 14y ago

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.

10char 14y ago
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 http://the-magazine.org/1/stables-and-volatiles
jakejake 14y ago
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.

joelmichael 14y ago

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.

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

simonbarker87 14y ago

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.

jyap 14y ago

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.

greatzebu 14y ago

> "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.

kwekly 14y ago
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.
- greatzebu 14y ago
  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.
Confusion 14y ago
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.

DanielRibeiro 14y ago

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 http://www.threeriversinstitute.org/blog/?p=251 [2] http://www.youtube.com/watch?v=KIkUWG5ACFY 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-process.html http://www.leanessays.com/2011/07/how-cadence-determines-pro... [4] http://swik.net/Eclipse/Planet+Eclipse/Julius+Shaw:+Kent+Beck+Revises+the+Agile+Manifesto+%28for+startups%29/d056n http://swik.net/Eclipse/Planet+Eclipse/Julius+Shaw:+Kent+Bec... [5] http://www.universalsubtitles.org/en/videos/6FfAAXK00nWB/en/182318/ http://www.universalsubtitles.org/en/videos/6FfAAXK00nWB/en/...

klibertp 14y ago

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.

mcantelon 14y ago
If you're a chef and you're consistantly asked to short order cook then change kitchens.
- lrobb 14y ago
  Or, change your utensils and embrace being a short order cook.
NinetyNine 14y ago
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.

greenyoda 14y ago

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 https://en.wikipedia.org/wiki/Technical_debt

imechura 14y ago

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.

mvanveen 14y ago
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.

iopq 14y ago

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?

elliottkember 14y ago

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.

BungleBob 14y ago

Lesson 1) The Kid is unemployable Lesson 2) That's why The Kid is The Boss. Be The Kid (or get a job).