4 ms·

I struggled with this a few times: “When a person signed up to do a job for him, he would in turn trust that person to accomplish it; he wouldn’t break it down

I struggled with this a few times: “When a person signed up to do a job for him, he would in turn trust that person to accomplish it; he wouldn’t break it down into little pieces and make the task small, easy and dull.” I’m not particularly talented, far from it actually, but many times I’ve worked in teams with non-junior people who were tasked to do some portion of a project, and simply delivered garbage: a terribly over engineered solution in a component where over engineering was actually very dangerous (e.g. doing distributed systems using several small bespoke moving parts rather than a single solid leader election mechanism, or even better getting away with something leaderless and more elegantly stateless, to give a recent example). In those occurrences, I inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, until the other person really had to finally move to a solution much more similar to the one I had in mind (much much simpler). Sometimes this required an embarrassing feedback loop of 10+ round trips, where every time I’d just look at the newly delivered code say “this doesn’t work in a X scenario”. And I was not in a better position from a knowledge perspective, we were essentially peers. I felt like a prick and definitely felt resentment from the other party (especially since code reviews are public), but at the same time, how could I have acted differently? The end result was really orders of magnitude better, more robust and smaller.

tonyarkles 8y ago
I wish I knew the answer to this, but I don’t. The closest I’ve come to succeeding at this is to have a reputation as a “breaker”. This really started in undergrad algorithms; I wasn’t great at finding solutions, but I had a knack for finding edge cases to break solutions others had come up with. Sometimes it just needed a tweak to work, sometimes it was “throw it all away and start over”. For the few times I’ve done regular office-style work over the years, that’s come in handy. I feel like a dick a too, but I try to be really gentle and end up with people showing up on their own to “run something by me” before building it out. Saves everyone frustration! There have been colleagues though who do exactly what you’ve described. That brutally painful loop of breaking pieces of an overly complicated solution over and over. My unfortunate confession is that I usually end up giving up and let them fail on their own. I’m always willing to help, but if someone doesn’t want help, I won’t spend much energy forcing it on them.
- korijn 8y ago
  IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned previously.
  - deanmoriarty 8y ago
    In my experience, it doesn’t work that way at all. What happens is that the code will be released, some user will hit the bug in the field, and the issue will be escalated to the engineer, who will proceed to spend entire days or weeks to troubleshoot the problem, and then just put a dirty patch that fixes the specific issue, leaving all the other corner conditions still exposed and ready to explode. At that point, major redesign of the solution, which would have been possible at the code review phase, will just be deemed too risky by both the engineer and the management. On top of this, Management, usually ignorant to concepts such as “over engineered solution”, will praise the heroic effort of the engineer who spent days troubleshooting the issue, clueless of the fact that it was a completely self inflicted wound because the engineer decided that the best way to calculate 2+2 is to really do sqrt(2^4) and then realized that the user really wanted to do 3+3, so they’re going to put a special case to evaluate 3+3 as sqrt(3^3+3^2) rather than just doing the damn x+y. Nobody will even realize that the issue could have been completely prevented in the first place by adopting a solution that was much easier to reason with on the whiteboard, rather than a house of cards of custom logic. I’ve seen this script dozens of time.
  - PhantomGremlin 8y ago
    That's a little easier to do for software, harder to do in the context of building hardware, which is what the book was about. Circa 1980, around the time of the events in the book, the time delays involved in making design changes to boards built from MSI building blocks were bad enough. Physical wire mods to a board took hours or days. New boards could be made in weeks or months. There was also some flexibility because parts of that design used PALs, which were easily reprogrammed. But in today's world the time cost of a re-spin of a CPU or a highly integrated SOC chip is huge. Months for simple changes, years for complete re-designs. Just look at the time estimates for hardware changes to x86 chips to mitigate Spectre and Meltdown. Some months for new microcode; many years for new silicon. Nevertheless, it's perhaps easier to let things happen and afterward think "I told you so". Because, unfortunately at most companies, if you try to impart those lessons earlier in the process, e.g. at design reviews, you quickly get the reputation of not being a "team player". Sounds crazy, but that's simple human nature.
taneq 8y ago
I'd assume that the key element here that they don't talk about is that he didn't keep people on his team who he couldn't trust to accomplish the tasks he set them.
blihp 8y ago
I've only seen it work when there's a combination of competence and ownership. i.e. someone from above can't just say 'this is yours, figure it out', the other party has to be able to do it and accept the ownership of it. Even when they can and do, there will inevitably be things they get wrong and/or miss but when those are pointed out they, assuming they've accepted ownership, will understand without being asked that it is for them to correct. If you try do it before someone is able or willing, it can turn into a train wreck. Also, I've found it much harder to do in larger organizations for a variety of reasons.
silveroriole 8y ago
When the coder is a peer and you’re not their mentor, manager, or lead, I normally keep code review comments to suggestions or questions - “What happens here in X scenario? Maybe we should refactor this part out into a stateless microservice?” That avoids the resentment and makes you look less like a control freak, but still shows your competency/foresight. If they choose not to take your advice, too bad for them, but I try to make sure they end up personally fixing the inevitable problems and hopefully learning from it. Other than that I haven’t found any great solution, but I have found it stressful and counter-productive to try and do EVERYONE’S thinking for them. They do not learn in that case, they just continue to outsource their thinking to you. e: also 10+ rounds is excessive for a peer review imo, after 2 or 3 I’d be having a higher level design chat with their lead/manager.
- jeffrallen 8y ago
  Other useful phrases: "Here, I was expecting to see...", "This code made me look at this other code and they cannot both be correct...", and "It took me a while to see why this is correct. We could save the next reader time by..." Excellent code reviews take time and attention, which is why you need auto code formatting and $lang proverbs to take the uncontroversial stuff off the table early. Then you still have brain power left to give value from the review. Also: work hard to earn a reputation as a fair but tough reviewer. Then when you need to be a prick, people will know it's important and let their ego down.
EliRivers 8y ago
The quote you quoted says "signed up to do a job for him", but then what you describe is people being "tasked to do some portion of a project". Is there a difference in that? If I sign up to do a job, that's quite different to having something assigned to me. Things I sign up for are things I have chosen, based on my abilities and enthusiasms; things that are assigned to me.. well, not so much.
- jsolson 8y ago
  That was my observation as well. I find the quality of work goes up dramatically when people are invested personally in the success of their part of it. "Signing up", to me, is about committing to that sort of investment, and it's the signal I look for to know if a team is going to be healthy. Not having that signal is a two-way street, though -- sometimes the answer is to restructure the work overall so that the pieces align better with what team members will sign up for.
sowbug 8y ago
Giving feedback doesn't necessitate micromanagement (which I'm using as a synonym for demanding a particular "how" in addition to an assignment of "what"). Would your experience have been better if you'd given the same high-level feedback as what you've shared with us? For example: "Hey, Non-Junior Person, your approach appears to be overengineered. For this application, overengineering isn't a matter of taste; it's a matter of safety. Please come up with a simpler approach."
notacoward 8y ago
I can't quite decide if this sounds great or awful. If code hasn't been adequately verified and/or tested, helping someone address those omissions (which would require fixing the bugs they make manifest) would be great. OTOH, merely "pointing out" or saying "this doesn't work" sounds not so great, and "similar to the one I had in mind" rings a huge NIH alarm bell. Instead of wondering whether you were being a prick, I'd highly recommend asking your other peers for suggestions on making the process less adversarial.
agumonkey 8y ago
in these situations I'd hope for people to naturally gather around positive ~negotiations. Open and constructive sharing of ideas.
mirceal 8y ago
over-engineering is real and is slowing things to a grind around you everyday. my conclusion is that people don’t really like simple things and they believe that complex=good and it’s a sign of how good/smart you are. so people are suckers for complexity. nobody is going to receive a medal or a promotion for well written and simple code that “just works”. you won’t know it’s there. now, the reaction you’re describing comes from the “i’ve seem some shit” syndrome where not only you can see the layers upon layers of unnecessary crud but you can also see how it’s going to break in the future. it’s terrifying.
geophile 8y ago
> I inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, ... I felt like a prick and definitely felt resentment from the other party (especially since code reviews are public) There's the problem, right there. Using a code review to expose a design flaw. I worked at my first startup starting in 1988, not long after SOANM came out. Most of the engineers at this company read the book. I was struck by the similarity between the situations and dynamics described in the book, and what I was observing first-hand. Our approach to engineering was academic in nature. This was remarkable because there was only one PhD in the bunch -- me, the most junior person -- and everyone but me had a spectacular track record of designing, building and delivering innovative products. We started with whiteboard discussions. These would go on for hours at a time, across multiple days. When we had the outlines of a workable idea, someone would go and write a design document. And that got reviewed extensively, over a few days. The "breaker" sorts of analyses got done at this point. So by the time we started implementing, we knew we had a very solid design. From that point on, bugs were just bugs. They weren't these initial cracks that revealed a rotten foundation. I thought that this approach worked incredibly well. And I was dismayed to observe that it wasn't practiced elsewhere. I did try to institute this approach a few times, but it doesn't really take hold unless you have other senior people who want to adopt it. And at my last startup, we had smart but young and inexperienced developers who were bought into Agile, and code reviews substituting for design reviews. The predictable (and predicted) hilarity ensued.
- deanmoriarty 8y ago
  Yeah, these days what you are describing is simply utopy, at least according to my experience spanning a single decade across two startups and two large companies. Engineers, once they are hired and passed the interview, are mostly seen as a commodity, in the sense that, in the eyes of management, every non-junior engineer should exactly be able to come up with the correct idea (modulo a short phase of code review, just in case), so the output they produce can just be as equally produced by a peer (just like a commodity): in that world view, design meetings spanning multiple days don't do much, and they just make you lose time against the current jira sprint. I would love to work in a place where management understood that collective intelligence is almost always superior than the initiative of a single person, and thus it's very important to have a design phase where as many engineers as possible are involved. Every single time I had to lead a significant project, I always spent so much time involving as many people as I could find to discuss the idea, constantly self doubting my ideas. Incidentally, very few significant bugs have occurred when the project was delivered, in contrast with the example I was quoting, where the thing was developed completely hermetically by another non-junior engineer, who failed to account for many non-to-rare corner cases.

tonyarkles 8y ago

I wish I knew the answer to this, but I don’t. The closest I’ve come to succeeding at this is to have a reputation as a “breaker”. This really started in undergrad algorithms; I wasn’t great at finding solutions, but I had a knack for finding edge cases to break solutions others had come up with. Sometimes it just needed a tweak to work, sometimes it was “throw it all away and start over”. For the few times I’ve done regular office-style work over the years, that’s come in handy. I feel like a dick a too, but I try to be really gentle and end up with people showing up on their own to “run something by me” before building it out. Saves everyone frustration! There have been colleagues though who do exactly what you’ve described. That brutally painful loop of breaking pieces of an overly complicated solution over and over. My unfortunate confession is that I usually end up giving up and let them fail on their own. I’m always willing to help, but if someone doesn’t want help, I won’t spend much energy forcing it on them.

korijn 8y ago
IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned previously.
- deanmoriarty 8y ago
  In my experience, it doesn’t work that way at all. What happens is that the code will be released, some user will hit the bug in the field, and the issue will be escalated to the engineer, who will proceed to spend entire days or weeks to troubleshoot the problem, and then just put a dirty patch that fixes the specific issue, leaving all the other corner conditions still exposed and ready to explode. At that point, major redesign of the solution, which would have been possible at the code review phase, will just be deemed too risky by both the engineer and the management. On top of this, Management, usually ignorant to concepts such as “over engineered solution”, will praise the heroic effort of the engineer who spent days troubleshooting the issue, clueless of the fact that it was a completely self inflicted wound because the engineer decided that the best way to calculate 2+2 is to really do sqrt(2^4) and then realized that the user really wanted to do 3+3, so they’re going to put a special case to evaluate 3+3 as sqrt(3^3+3^2) rather than just doing the damn x+y. Nobody will even realize that the issue could have been completely prevented in the first place by adopting a solution that was much easier to reason with on the whiteboard, rather than a house of cards of custom logic. I’ve seen this script dozens of time.
- PhantomGremlin 8y ago
  That's a little easier to do for software, harder to do in the context of building hardware, which is what the book was about. Circa 1980, around the time of the events in the book, the time delays involved in making design changes to boards built from MSI building blocks were bad enough. Physical wire mods to a board took hours or days. New boards could be made in weeks or months. There was also some flexibility because parts of that design used PALs, which were easily reprogrammed. But in today's world the time cost of a re-spin of a CPU or a highly integrated SOC chip is huge. Months for simple changes, years for complete re-designs. Just look at the time estimates for hardware changes to x86 chips to mitigate Spectre and Meltdown. Some months for new microcode; many years for new silicon. Nevertheless, it's perhaps easier to let things happen and afterward think "I told you so". Because, unfortunately at most companies, if you try to impart those lessons earlier in the process, e.g. at design reviews, you quickly get the reputation of not being a "team player". Sounds crazy, but that's simple human nature.

taneq 8y ago

I'd assume that the key element here that they don't talk about is that he didn't keep people on his team who he couldn't trust to accomplish the tasks he set them.

blihp 8y ago

I've only seen it work when there's a combination of competence and ownership. i.e. someone from above can't just say 'this is yours, figure it out', the other party has to be able to do it and accept the ownership of it. Even when they can and do, there will inevitably be things they get wrong and/or miss but when those are pointed out they, assuming they've accepted ownership, will understand without being asked that it is for them to correct. If you try do it before someone is able or willing, it can turn into a train wreck. Also, I've found it much harder to do in larger organizations for a variety of reasons.

silveroriole 8y ago

When the coder is a peer and you’re not their mentor, manager, or lead, I normally keep code review comments to suggestions or questions - “What happens here in X scenario? Maybe we should refactor this part out into a stateless microservice?” That avoids the resentment and makes you look less like a control freak, but still shows your competency/foresight. If they choose not to take your advice, too bad for them, but I try to make sure they end up personally fixing the inevitable problems and hopefully learning from it. Other than that I haven’t found any great solution, but I have found it stressful and counter-productive to try and do EVERYONE’S thinking for them. They do not learn in that case, they just continue to outsource their thinking to you. e: also 10+ rounds is excessive for a peer review imo, after 2 or 3 I’d be having a higher level design chat with their lead/manager.

jeffrallen 8y ago
Other useful phrases: "Here, I was expecting to see...", "This code made me look at this other code and they cannot both be correct...", and "It took me a while to see why this is correct. We could save the next reader time by..." Excellent code reviews take time and attention, which is why you need auto code formatting and $lang proverbs to take the uncontroversial stuff off the table early. Then you still have brain power left to give value from the review. Also: work hard to earn a reputation as a fair but tough reviewer. Then when you need to be a prick, people will know it's important and let their ego down.

EliRivers 8y ago

The quote you quoted says "signed up to do a job for him", but then what you describe is people being "tasked to do some portion of a project". Is there a difference in that? If I sign up to do a job, that's quite different to having something assigned to me. Things I sign up for are things I have chosen, based on my abilities and enthusiasms; things that are assigned to me.. well, not so much.

jsolson 8y ago
That was my observation as well. I find the quality of work goes up dramatically when people are invested personally in the success of their part of it. "Signing up", to me, is about committing to that sort of investment, and it's the signal I look for to know if a team is going to be healthy. Not having that signal is a two-way street, though -- sometimes the answer is to restructure the work overall so that the pieces align better with what team members will sign up for.

sowbug 8y ago

Giving feedback doesn't necessitate micromanagement (which I'm using as a synonym for demanding a particular "how" in addition to an assignment of "what"). Would your experience have been better if you'd given the same high-level feedback as what you've shared with us? For example: "Hey, Non-Junior Person, your approach appears to be overengineered. For this application, overengineering isn't a matter of taste; it's a matter of safety. Please come up with a simpler approach."

notacoward 8y ago

I can't quite decide if this sounds great or awful. If code hasn't been adequately verified and/or tested, helping someone address those omissions (which would require fixing the bugs they make manifest) would be great. OTOH, merely "pointing out" or saying "this doesn't work" sounds not so great, and "similar to the one I had in mind" rings a huge NIH alarm bell. Instead of wondering whether you were being a prick, I'd highly recommend asking your other peers for suggestions on making the process less adversarial.

agumonkey 8y ago

in these situations I'd hope for people to naturally gather around positive ~negotiations. Open and constructive sharing of ideas.

mirceal 8y ago

over-engineering is real and is slowing things to a grind around you everyday. my conclusion is that people don’t really like simple things and they believe that complex=good and it’s a sign of how good/smart you are. so people are suckers for complexity. nobody is going to receive a medal or a promotion for well written and simple code that “just works”. you won’t know it’s there. now, the reaction you’re describing comes from the “i’ve seem some shit” syndrome where not only you can see the layers upon layers of unnecessary crud but you can also see how it’s going to break in the future. it’s terrifying.

geophile 8y ago

> I inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, ... I felt like a prick and definitely felt resentment from the other party (especially since code reviews are public) There's the problem, right there. Using a code review to expose a design flaw. I worked at my first startup starting in 1988, not long after SOANM came out. Most of the engineers at this company read the book. I was struck by the similarity between the situations and dynamics described in the book, and what I was observing first-hand. Our approach to engineering was academic in nature. This was remarkable because there was only one PhD in the bunch -- me, the most junior person -- and everyone but me had a spectacular track record of designing, building and delivering innovative products. We started with whiteboard discussions. These would go on for hours at a time, across multiple days. When we had the outlines of a workable idea, someone would go and write a design document. And that got reviewed extensively, over a few days. The "breaker" sorts of analyses got done at this point. So by the time we started implementing, we knew we had a very solid design. From that point on, bugs were just bugs. They weren't these initial cracks that revealed a rotten foundation. I thought that this approach worked incredibly well. And I was dismayed to observe that it wasn't practiced elsewhere. I did try to institute this approach a few times, but it doesn't really take hold unless you have other senior people who want to adopt it. And at my last startup, we had smart but young and inexperienced developers who were bought into Agile, and code reviews substituting for design reviews. The predictable (and predicted) hilarity ensued.

deanmoriarty 8y ago
Yeah, these days what you are describing is simply utopy, at least according to my experience spanning a single decade across two startups and two large companies. Engineers, once they are hired and passed the interview, are mostly seen as a commodity, in the sense that, in the eyes of management, every non-junior engineer should exactly be able to come up with the correct idea (modulo a short phase of code review, just in case), so the output they produce can just be as equally produced by a peer (just like a commodity): in that world view, design meetings spanning multiple days don't do much, and they just make you lose time against the current jira sprint. I would love to work in a place where management understood that collective intelligence is almost always superior than the initiative of a single person, and thus it's very important to have a design phase where as many engineers as possible are involved. Every single time I had to lead a significant project, I always spent so much time involving as many people as I could find to discuss the idea, constantly self doubting my ideas. Incidentally, very few significant bugs have occurred when the project was delivered, in contrast with the example I was quoting, where the thing was developed completely hermetically by another non-junior engineer, who failed to account for many non-to-rare corner cases.