4 ms·

I tend to think most of engineering is rather mundane but potentially very rewarding. I hate meetings and overly complicated project coordination just as much t

I tend to think most of engineering is rather mundane but potentially very rewarding. I hate meetings and overly complicated project coordination just as much the next person but there is also danger in wanting to do ‘cool stuff’ - imagine a dentist who is passionate about pulling teeth out. A project that I quite enjoyed involved months of investigation work, finally solved by tweaking a single software parameter that dictated how far a release mechanism moved. The number of internal/external meetings I had to demonstrate that this can indeed fix the problem could have seemed silly but it was also very reasonable given the risks involved.

formerly_proven 4y ago
> I hate meetings and overly complicated project coordination just as much the next person but there is also danger in wanting to do ‘cool stuff’ - imagine a dentist who is passionate about pulling teeth out. There was a case here were an (employed) dentist was apparently bored and started to drill and fill perfectly healthy teeth. Iirc, criminal charges were filed. Malpractice because bored (or feeling undervalued/underappreciated etc.) isn't just a problem for SWEs, but actual doctors. Also see: nurses and doctors inducing code blues to get to be the hero saving the patient; firemen becoming arsonists to have a fire to extinguish.
- xpe 4y ago
  What are some estimates for the likelihood of these behaviors? In dentistry? 1 of every ... ? 1,000 teeth? More? Less?
  - pixl97 4y ago
    Not sure how many good studies there are on it, but the likelihood of an unnecessary operation occurring are strongly linked to that months financials. https://www.theguardian.com/society/2000/apr/16/futureofthenhs.health https://www.theguardian.com/society/2000/apr/16/futureofthen...
ethbr0 4y ago
> imagine a dentist who is passionate about pulling teeth out That's a great metaphor for code-before-you-know developers. > finally solved by tweaking a single software parameter that dictated how far a release mechanism moved I think of this type of work as programming by other means. The problem couldn't have been "fixed" without all the discovery meetings and understanding. The "fix" couldn't have made it to production without political agreement. Is that computer code? No. Is it building a solution to interact with a complex system (of people), using the primitives available to you (less than VP-style "Just do it"), to realize a desired outcome? Yes. Others may be different, but I find hacking obtuse process problems and corporate political structures just as fun and rewarding as a nice piece of code.
- nickjj 4y ago
  > Imagine a dentist who is passionate about pulling teeth out ... That's a great metaphor for code-before-you-know developers. A key difference between a big decision and a small decision is what it's like to change your decision afterwards. I don't think we can compare reverting a pulled tooth vs 2 hours of programming the "wrong" thing. In the programming case, you may have went down a rabbit hole that wasn't correct but at least now you're 1 step closer to the right solution. You probably learned something and the business can write that off as R&D. In the pulled tooth case, well, I'm not sure I want to Google that haha. Is it possible to fully replant a pulled tooth in a way where it's 100% healthy and you'd never notice it was pulled? I know there's implants but I mean the real natural tooth, complete with its root. I'm sure the process in any case would not be fun for the person who needs the work done. You could classify one of these as a small decision and the other one as large. I still think planning and understanding the problem before coding most things is a very good idea btw, but I would feel way more comfortable experimenting with code in short periods of time vs experimenting in a dental chair / operating room.
  - pc86 4y ago
    I maybe wrong but let me paraphrase what I think they meant (and why I think it's a great analogy). I don't want my teeth pulled just because. If it's a fix to a problem - a means to an end - and there's no other way to do it, I'll consider it. Likewise, I don't want to work with developers who are super passionate about typing code into vim. I want to work with developers who are passionate about solving problems. Code can be a means to that end, and by the time it gets to us we typically already know we need some code for it, but the danger is spending days or weeks writing code nobody needs and nobody asked for because it's "their passion."
bambax 4y ago
> imagine a dentist who is passionate about pulling teeth out Exactly. Many times, the best code is no code. And making decisions about what code to write need meetings, unfortunately, or at the very least some kind of coordination.
- Ekaros 4y ago
  There is really some questions that should be asked: Why are we doing this? For what reason it has to be done this way? Do we need to do this at all? What do you actually want? And so on. Meetings are useful to clear up this stuff and at best result there is simpler solution, or not need to do work at all.
  - xpe 4y ago
    Yes, some kinds of meetings can be useful. The author of the post, in my reading, laments petty meetings not productive ones.
  - ratww 4y ago
    However it is often the case that programmers "at the leaves of org charts" (to paraphrase another commenter) won't get to participate on meetings that can define if something can be replaced by "less code", let alone "no code". In small orgs with a headcount of tens that's very easy for developers to grasp the value and the need for certain things. But when you're in a 1000+ developer organization it is often the case that the reason you have to do something is because this is a requirement coming from two or three management levels above. In some orgs, a lowly developer might even be unable to even sit at the table with the big boys. They might have a say and a good perspective in micro decisions, but not in macro ones. In this case, I can definitely see TFA being written. To use the dentist example, imagine a dentist that's passionate about pulling teeth, but doesn't get a say on wether the teeth should be pulled or not.

formerly_proven 4y ago

> I hate meetings and overly complicated project coordination just as much the next person but there is also danger in wanting to do ‘cool stuff’ - imagine a dentist who is passionate about pulling teeth out. There was a case here were an (employed) dentist was apparently bored and started to drill and fill perfectly healthy teeth. Iirc, criminal charges were filed. Malpractice because bored (or feeling undervalued/underappreciated etc.) isn't just a problem for SWEs, but actual doctors. Also see: nurses and doctors inducing code blues to get to be the hero saving the patient; firemen becoming arsonists to have a fire to extinguish.

xpe 4y ago
What are some estimates for the likelihood of these behaviors? In dentistry? 1 of every ... ? 1,000 teeth? More? Less?
- pixl97 4y ago
  Not sure how many good studies there are on it, but the likelihood of an unnecessary operation occurring are strongly linked to that months financials. https://www.theguardian.com/society/2000/apr/16/futureofthenhs.health https://www.theguardian.com/society/2000/apr/16/futureofthen...

ethbr0 4y ago

> imagine a dentist who is passionate about pulling teeth out That's a great metaphor for code-before-you-know developers. > finally solved by tweaking a single software parameter that dictated how far a release mechanism moved I think of this type of work as programming by other means. The problem couldn't have been "fixed" without all the discovery meetings and understanding. The "fix" couldn't have made it to production without political agreement. Is that computer code? No. Is it building a solution to interact with a complex system (of people), using the primitives available to you (less than VP-style "Just do it"), to realize a desired outcome? Yes. Others may be different, but I find hacking obtuse process problems and corporate political structures just as fun and rewarding as a nice piece of code.

nickjj 4y ago
> Imagine a dentist who is passionate about pulling teeth out ... That's a great metaphor for code-before-you-know developers. A key difference between a big decision and a small decision is what it's like to change your decision afterwards. I don't think we can compare reverting a pulled tooth vs 2 hours of programming the "wrong" thing. In the programming case, you may have went down a rabbit hole that wasn't correct but at least now you're 1 step closer to the right solution. You probably learned something and the business can write that off as R&D. In the pulled tooth case, well, I'm not sure I want to Google that haha. Is it possible to fully replant a pulled tooth in a way where it's 100% healthy and you'd never notice it was pulled? I know there's implants but I mean the real natural tooth, complete with its root. I'm sure the process in any case would not be fun for the person who needs the work done. You could classify one of these as a small decision and the other one as large. I still think planning and understanding the problem before coding most things is a very good idea btw, but I would feel way more comfortable experimenting with code in short periods of time vs experimenting in a dental chair / operating room.
- pc86 4y ago
  I maybe wrong but let me paraphrase what I think they meant (and why I think it's a great analogy). I don't want my teeth pulled just because. If it's a fix to a problem - a means to an end - and there's no other way to do it, I'll consider it. Likewise, I don't want to work with developers who are super passionate about typing code into vim. I want to work with developers who are passionate about solving problems. Code can be a means to that end, and by the time it gets to us we typically already know we need some code for it, but the danger is spending days or weeks writing code nobody needs and nobody asked for because it's "their passion."

bambax 4y ago

> imagine a dentist who is passionate about pulling teeth out Exactly. Many times, the best code is no code. And making decisions about what code to write need meetings, unfortunately, or at the very least some kind of coordination.

Ekaros 4y ago
There is really some questions that should be asked: Why are we doing this? For what reason it has to be done this way? Do we need to do this at all? What do you actually want? And so on. Meetings are useful to clear up this stuff and at best result there is simpler solution, or not need to do work at all.
- xpe 4y ago
  Yes, some kinds of meetings can be useful. The author of the post, in my reading, laments petty meetings not productive ones.
- ratww 4y ago
  However it is often the case that programmers "at the leaves of org charts" (to paraphrase another commenter) won't get to participate on meetings that can define if something can be replaced by "less code", let alone "no code". In small orgs with a headcount of tens that's very easy for developers to grasp the value and the need for certain things. But when you're in a 1000+ developer organization it is often the case that the reason you have to do something is because this is a requirement coming from two or three management levels above. In some orgs, a lowly developer might even be unable to even sit at the table with the big boys. They might have a say and a good perspective in micro decisions, but not in macro ones. In this case, I can definitely see TFA being written. To use the dentist example, imagine a dentist that's passionate about pulling teeth, but doesn't get a say on wether the teeth should be pulled or not.