6 ms·

10x or not: You’ve got to do things right

48 points by tiwarinitish86 10y ago

draw_down 10y ago
Instead of a "no shaming" culture, I'd like to find a culture of "don't fuck up". "No shaming" and "no assholes" just leads to people cheerily and politely fucking up.
- Animats 10y ago
  You want NASA in the Apollo era. Read "Failure is not an option".[1] [1] http://www.amazon.com/Failure-Not-Option-Mission-Control/dp/0783891369 http://www.amazon.com/Failure-Not-Option-Mission-Control/dp/...
- dang 10y ago
  Don't the two go together? Shame drives people to cover up their mistakes. That produces more fuckups. There's an old improv game where someone suddenly points to you and you have to continue their story without missing a beat and without doing a bunch of other arbitrary things. It's designed to be impossible. But if—or rather when—you fuck up, the rule is that everybody applauds, praises you, and gives you hugs. It's disorienting at first, but then you can feel yourself acquiring entirely new patterns in response to mistakes.
- tbrownaw 10y ago
  The thing is, trying to demand absolute perfection results in the inevitable imperfections getting hidden. If you want them to get fixed, there can't be any incentive to hide them. Which is where "no shaming" rules come from.
- rauljara 10y ago
  In my experience, a no shaming culture is one where mistakes get fixed instead of hidden, and everyone can learn from them. Fwiw, I work for trading firm, which trades 10+ billion dollars daily and mistakes can be incredibly costly. I would argue the lack of shame associated with admitting mistakes is vital to our level of code quality. I have yet to meet the developer who does not make mistakes. I have met a few arrogant enough that they'd never admit to them.
- rhizome 10y ago
  Ah, "don't fuck up," I wonder why nobody's thought of that before. It sounds like maybe you don't like your coworkers these days?
- jschwartzi 10y ago
  I would rather know about something early so that I can fix it. If your entire business culture is one of berating people for making mistakes and introducing bugs, I can guarantee you that there are some really good latent ones that will bite you in the ass some day. God help you if peoples' lives actually depend on the code you write.
  - AceyMan 10y ago
    I'm won't be the first HN'er to note that the business of aviation has evolved a culture much like the ideal being discussed. You can see it when you read NTSB AARs, TSBs, even the regs (FARs) themselves. Even the language is chosen so as to avoid shame. When blame is ascribed it's explicit and for the purpose of explication of root causes, but, more generally, the tone of the narrative is always, "we've critiqued _the process_ and here's how we see to improve it." People are only seen as participants in the process and aren't targeted for blame or shame. The amazing safety statistics of commercial flight speak to the efficacy of this philosophy; software project management would do well to adopt much of these strategies, I'd argue.
- lsh 10y ago
  Upvoted, because I don't see a culture of working hard to not fuck up and shaming being mutually exclusive. Shaming is a poisonous behaviour but so is the belief we're capable of perfection. So also is the idea that we should be tolerant of those who constantly fuck up. Fuck those who can't/won't improve. If we put the infrastructure and attitudes in place that assumes that we will definitely fuck up, that sub-optimal solutions and people will be introduced, then fucking up becomes less common, communication isn't inhibited by shaming/bulling attitudes and, god forbid, we can raise our individual and collective standards and become more attuned to stink and how best to amortize it. Everything can be automated, even quality checks.
- ljw1001 10y ago
  There is no such thing as culture of "DO fuck up", only cultures where avoiding mistakes is secondary to other goals like hitting the schedule date.
- insanejudge 10y ago
  There's a huge difference between a "no shaming" culture and a "don't be ashamed" culture. It's critical for people to be able to be open and transparent about their mistakes and the process leading to them without fear of being put through the ringer for it, but that's not mutually exclusive from an environment where the type of appropriate embarrassment/remorse necessary (usually in the form of a thorough postmortem) to truly learn from one's errors is expected.
venomsnake 10y ago
If your name is Alice and you live in Wonderland. Or Harry in Hogwarts. In the real where requirements change constantly, libraries that you rely on rely on left-pad, budgets are short - or hell people just learn to write better code - so the old need to be refactored - the debt accumulates. Code debt is like entropy - always goes up. The normal state of a software project is under staffer, under budgeted, in constant flux requirement wise and for yesterday. Doing it right with reviews, refactoring, consistently is a luxury. You can try to have a process that minimizes chaos to minimum, but every project will devolve into unmaintainable mess. You cannot afford to be pure while you have the huge state monad called rest of the world that gives its best to crush you.
- sgift 10y ago
  Like every "we are doomed" answer there's a core of truth in here: If something is used and/or changed it will probably break down. Given that and trying to use it as starting point for something more helpful: Sofware is nothing special here. Your things will - depending on their quality - break down with time, especially when you tinker with them and/or use them. You can push this further into the future using maintenance, repairing damaged parts and so on, but at some point you will have repaired so much that you will in essence have a new thing, not the old thing anymore. The task is to balance your efforts with your use case. An engine which has to work for one formula one race is constructed very different from one which has to work 200 or 300k kilometers. Again, software is nothing special here. If your software has to work for one run "doing it right" may be a luxury. If you need your software for years to come your luxury becomes necessity.
conorgil145 10y ago
The article referenced in the blog post is also quite good: http://thenewstack.io/10x-programmer-just-jerk/ http://thenewstack.io/10x-programmer-just-jerk/
miguelrochefort 10y ago
"Right" is never fully defined, and keeps changing. Therefore, you can never do the right thing. My solution is radical, but necessary. 99.999% of code should never be written. Let's start saying no to businesses with arbitrary demands, and let's all agree on a set of standards. Only then will we have affordable and quality software.
- jpgvm 10y ago
  If we did that then we might actually start resembling a field of engineering. Unfortunately software is much more nebulous than structural, mechanical and other fields of engineering. There are less clear cut right and wrong things to do. Part of what gives software it's unique advantage in today's world is it's ability to change to meet evolving demands quicker than any other way of formulating solutions. As such unclear specifications are somewhat of a pillar of software engineering. However with unclear and perhaps rapidly changing specifications comes a lot of judgement calls on what to build, how to build and what are reasonable shortcuts to take. Software engineers are almost alone in this, most other professions have the "correct" way and all the ways you can do it wrong. In software there is no "correct" way and just many different ways of kinda achieving something "right".
  - Fiahil 10y ago
    I guess, if it was possible to build towers and bridges at the same speed we build software projects, we would see the same level of nebulousness appear.
- asimuvPR 10y ago
  What do you mean exactly?
- carterehsmith 10y ago
  "99.999% of code should never be written" Interesting. So if you are a freelancer, you will reject 99.999% of would-be customers. Not exactly a winning formula. Or, if you work for some kind of organization, you tell them, 99.999% of the time, that the business demands are "unreasonable" and that code should not be written. That will get you fired. Either way, I am not sure where you are going with that narrative.
vmarsy 10y ago
All all the tools mentioned and similar tools are great and it would be a good idea to integrate them in the development process, but I don't think they're that useful to diminish technical debt. Technical debt to me is uncessary dependencies, anti patterns etc. The only way to prevent this is a good code review were people pay attention to such things. Ideally the code author and the reviewers have the right thinking: after checking for correctness, they ask themselves "is this code modular/reusable/easily testable/easy to debug/..." Hopefully the testing is already here, but that's in a perfect situation
Xcelerate 10y ago
> Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. Perhaps this is a true statement; however, I have no doubt that 10x programmers do exist who do not build technical debt into the application. Some people really are that good. I don't think the average person realizes exactly how good the best in the world are at what they do. For instance, I ran track for 8 years and competed in college. You don't realize exactly how insane a 12:37 5K is until you've trained as hard as you can for years and you're not even close to that time. Nor do you realize how difficult a perfect rendition of Liszt's transcendental etudes are until you've spent years trying to learn them on your own. I imagine the best programmers in the world are similar, but it would take the average programmer decades of programming before the magnitude of the skill gap becomes evident.
- ljw1001 10y ago
  10X programmers are unicorns. If a 5K of 12:57 was really "10X", an average runner would take just over two hours. That performance is nothing like 10X.
  - bdcravens 10y ago
    I don't think that's a good analogy - a run has a very defined course, a very defined technique (you must run, not use a motorcycle), and very defined end point. Most programming problems have infinite solutions, and you're typical 1x developer can only see what they know and have experienced. To carry the analogy forward, a 10x runner might take a shortcut, use a better implement to complete the course, etc.
    - dasil003 10y ago
      Yeah a (slightly) better sporting analogy might be chess. Like chess, programming is a game of knowledge and forethought, where intelligence is an asset, but far from sufficient to elevate you without a ton of practice. However unlike chess, there is no scope or rigid definition of programming, it is as if there were as many pieces with different rules as there are possible positions on a chessboard, and furthermore that the rules of the pieces are made up themselves of subpieces all of which are programmable, and that you can essentially change everything from the behavior of the squares up to the overarching rules. Now in chess, as in programming, there are clearly some individuals who excel by orders of magnitude over beginners and even average competent players. But because of the vast scope of possibility, programming "grandmasters" will do things that no one else could have even thought of in one domain, while in unfamiliar domains they might require a good deal of study before they surpass the average journeyman practitioner. Meh, analogies suck.
xiaoma 10y ago
It's interesting how different this advice is from what some of the greatest engineering cultures have done. At Microsoft during its heyday in the 90s, it was common for people to say things like, "That's the dumbest fucking idea I've ever heard" and the behavior came straight from the top. Similarly, Steve Jobs and Jeff Bezos are well known for humiliating engineers in front of an entire room after a presentation. http://www.businessinsider.com/things-amazons-jeff-bezos-tells-employees-when-he-gets-angry-2013-10 http://www.businessinsider.com/things-amazons-jeff-bezos-tel... There's no way to prove the issue definitively either way, but I suspect this blog post suffers from the cognitive bias of confusing how the world should be with how it is. At the very least, a "no shaming" rule isn't a requirement for building a world-class engineering organization and attracting top talent.
- ArkyBeagle 10y ago
  I've worked for real jerks before. I don't think the economics of it work out. This being said, you learn a certain stoicism in the face of it. If you catch a real rant, a stone cold "You finished?" at the end might be in order. Don't get me wrong, I've raised my voice at people but only after they've persisted in a particular error for months, after receiving many many external reference to why it's an error. I've no interest in working for a Bezos-type because I see that as a "cult of personality". It's something people have to work around. If people are risk averse to sharing ideas, then you'll get fewer of them. Perhaps that's a good thing. But it costs very little to learn to provide feedback in a non-confrontational manner.
- ovt 10y ago
  I imagine how well people tolerate what they shouldn't has something to do with being Authoritarian Followers. And something maybe connected with those who glory in hazing culture. And we must grow past that kind of idiocy. If I worked for someone who treated me like that and then, decades later, I heard that they'd finally died, I'd say IT'S ABOUT FUCKING TIME! and have a little party.
  - quietplatypus 10y ago
    I think I know what you're talking about when you mention Authoritarian Followers---something like abused kids who only know how to deal with situations in which they are abused, even when they grow up. The worse part is they want to have "followers" themselves as well, subconsciously, repeating the cycle. I still have many properties of Authoritarian Followerism in myself, but I'm making progress. One of the difficult parts is many people around me show blatant signs of that followerism and it's easy to get sucked back down with them. E.g., a coworker protested my protestations against our company stack ranking employees based on "quantitative" metrics, and then many months later backpedaled on his words when someone who had a more important title said the same concerns.
issa 10y ago
In my experience, the most important skill in an engineer is figuring out what to build. Someone's skill at the actual task of programming is trivial in comparison.
im_down_w_otp 10y ago
I'm pretty sure the marketplace has decided that doing things "right" isn't particularly valuable. There are places currently where you'd expect an extremely high degree of rigor to be applied to a variety of engineering and technology problems because the potential financial impact of a cluster of interrelated faults would be irreparably financially and reputationally disastrous. But instead you will often find the overwhelming culture is to instead hire legions of employees/contractors ranging from demonstrably incompetent to tacitly complicit in knowingly producing garbage just so long as that garbage can be produced on reliably unrealistic (were any amount of rigor to be applied) timelines, and where the optics of "progress" vastly outweigh the quality of releases. And while none of this would be a spoken or agreed upon culture, the set of incentives in place guarantee that results do not align with the institutional rhetoric. And as much as it pains me personally to see cultures like that (as a 1x engineer who labors naively over correctness in design and implementation)... for the most part I think the marketplace got this right. If you consider realistically that the percentage of software programmers/developers/engineers/architects who work on something truly "mission critical"/"carrier grade"/"matter of life and death" is a rounding error compared to the number which work on the next Dashboards as a Service, or Fitbits for Dogs, or next-gen tween sexting mobile platform, or just toiling away fruitlessly on shelf-ware in large directionless companies surviving on the carcasses of well-heeled dinosaurs in their "enterprise sales channels", then quite obviously doing things "right" comes along with almost no actual value other than just the ability to claim you did it that way. If building most software came with anything remotely resembling the risk and liability of building a high-rise apartment building, or a suspension bridge, or the hydraulic controls of a jetliner, then one would likely see much more common practice, conventions, and thorough auditing of software that gets created. Rather than "best practices" being outliers, they'd be the norm, and they'd be much more codified and immutable than simply the most recent blog post about scar tissue earned from a metaphorical software skyscraper collapsing into The Bay one sunny Tuesday afternoon. As an informal support of the above claim. How many among us have worked on projects which included, as a central pillar of the engineering process and culture, all the following forms of testing... unit, integration, property-based, concolic, end-to-end, chaos, regression, soak, and mutation, and have indefinitely pushed back releases until all those forms of testing could be exercised and validated? Whatever the number I'd wager a year's salary that there are more people who don't even know what most of those things are than the number which have been required to diligently do all of them. Probably by an order of magnitude. If we're talking about mythological 10x unicorns, perhaps we can start with that one?
vigilant 10y ago
The reason the debt metaphor is used for technical debt is that debt isn't necessarily a bad thing - it just something to understand and manage. Most people, when they buy a house, go into debt (e.g.: a mortgage) for the initial purchase - without that debt, they would never be able to save up the money needed to buy that house. A startup seems similar - the first goal of a startup should be to show traction and market fit before running out of runway - and if building up technical debt lets them achieve that more quickly, then that is the right thing to do. This first phase seems to be where the 10x programming would shine.
- pacala 10y ago
  Great point. Debt is a necessary part of bootstrapping a new project. That being said, technical debt is not a blanket excuse for violating elementary engineering precepts, shipping shoddy components full of bugs or a necessary evil part of the final product. The team must be able to be specific about the technical debt and execute a reasonable plan to repay it.
  - mpbm 10y ago
    Technical debt actually isn't a great metaphor. It breaks down too quickly, as in this case. You don't have to "repay" technical debt. It's not really debt. A company only needs to build something that works. If it works in spite of violating elementary design precepts, shoddy components, bugs, and necessary evil, then it still works. The only thing that matters is the result. Investing resources into optimizing it so that it works better than necessary is merely an option, whereas getting it to work wasn't. The iron triangle includes cost and schedule in addition to performance. If it would take more money or time than you have to make it perform better, then it just won't, because you don't have that much money or time. A product that frightens the maintainers, but keeps the lights on, is a good result. Of course, you might optimize yourself into a local maximum if you're weak on strategy. That's why nearly every organization in the world has some kind of separation between "officer/executive" and "enlisted/staff" in the hierarchy. Someone needs to balance the triangle and someone needs to write code and there isn't enough time for the same person to do both.

Instead of a "no shaming" culture, I'd like to find a culture of "don't fuck up". "No shaming" and "no assholes" just leads to people cheerily and politely fucking up.

Animats 10y ago
You want NASA in the Apollo era. Read "Failure is not an option".[1] [1] http://www.amazon.com/Failure-Not-Option-Mission-Control/dp/0783891369 http://www.amazon.com/Failure-Not-Option-Mission-Control/dp/...
dang 10y ago
Don't the two go together? Shame drives people to cover up their mistakes. That produces more fuckups. There's an old improv game where someone suddenly points to you and you have to continue their story without missing a beat and without doing a bunch of other arbitrary things. It's designed to be impossible. But if—or rather when—you fuck up, the rule is that everybody applauds, praises you, and gives you hugs. It's disorienting at first, but then you can feel yourself acquiring entirely new patterns in response to mistakes.
tbrownaw 10y ago
The thing is, trying to demand absolute perfection results in the inevitable imperfections getting hidden. If you want them to get fixed, there can't be any incentive to hide them. Which is where "no shaming" rules come from.
rauljara 10y ago
In my experience, a no shaming culture is one where mistakes get fixed instead of hidden, and everyone can learn from them. Fwiw, I work for trading firm, which trades 10+ billion dollars daily and mistakes can be incredibly costly. I would argue the lack of shame associated with admitting mistakes is vital to our level of code quality. I have yet to meet the developer who does not make mistakes. I have met a few arrogant enough that they'd never admit to them.
rhizome 10y ago
Ah, "don't fuck up," I wonder why nobody's thought of that before. It sounds like maybe you don't like your coworkers these days?
jschwartzi 10y ago
I would rather know about something early so that I can fix it. If your entire business culture is one of berating people for making mistakes and introducing bugs, I can guarantee you that there are some really good latent ones that will bite you in the ass some day. God help you if peoples' lives actually depend on the code you write.
- AceyMan 10y ago
  I'm won't be the first HN'er to note that the business of aviation has evolved a culture much like the ideal being discussed. You can see it when you read NTSB AARs, TSBs, even the regs (FARs) themselves. Even the language is chosen so as to avoid shame. When blame is ascribed it's explicit and for the purpose of explication of root causes, but, more generally, the tone of the narrative is always, "we've critiqued _the process_ and here's how we see to improve it." People are only seen as participants in the process and aren't targeted for blame or shame. The amazing safety statistics of commercial flight speak to the efficacy of this philosophy; software project management would do well to adopt much of these strategies, I'd argue.
lsh 10y ago
Upvoted, because I don't see a culture of working hard to not fuck up and shaming being mutually exclusive. Shaming is a poisonous behaviour but so is the belief we're capable of perfection. So also is the idea that we should be tolerant of those who constantly fuck up. Fuck those who can't/won't improve. If we put the infrastructure and attitudes in place that assumes that we will definitely fuck up, that sub-optimal solutions and people will be introduced, then fucking up becomes less common, communication isn't inhibited by shaming/bulling attitudes and, god forbid, we can raise our individual and collective standards and become more attuned to stink and how best to amortize it. Everything can be automated, even quality checks.
ljw1001 10y ago
There is no such thing as culture of "DO fuck up", only cultures where avoiding mistakes is secondary to other goals like hitting the schedule date.
insanejudge 10y ago
There's a huge difference between a "no shaming" culture and a "don't be ashamed" culture. It's critical for people to be able to be open and transparent about their mistakes and the process leading to them without fear of being put through the ringer for it, but that's not mutually exclusive from an environment where the type of appropriate embarrassment/remorse necessary (usually in the form of a thorough postmortem) to truly learn from one's errors is expected.

venomsnake 10y ago

If your name is Alice and you live in Wonderland. Or Harry in Hogwarts. In the real where requirements change constantly, libraries that you rely on rely on left-pad, budgets are short - or hell people just learn to write better code - so the old need to be refactored - the debt accumulates. Code debt is like entropy - always goes up. The normal state of a software project is under staffer, under budgeted, in constant flux requirement wise and for yesterday. Doing it right with reviews, refactoring, consistently is a luxury. You can try to have a process that minimizes chaos to minimum, but every project will devolve into unmaintainable mess. You cannot afford to be pure while you have the huge state monad called rest of the world that gives its best to crush you.

sgift 10y ago
Like every "we are doomed" answer there's a core of truth in here: If something is used and/or changed it will probably break down. Given that and trying to use it as starting point for something more helpful: Sofware is nothing special here. Your things will - depending on their quality - break down with time, especially when you tinker with them and/or use them. You can push this further into the future using maintenance, repairing damaged parts and so on, but at some point you will have repaired so much that you will in essence have a new thing, not the old thing anymore. The task is to balance your efforts with your use case. An engine which has to work for one formula one race is constructed very different from one which has to work 200 or 300k kilometers. Again, software is nothing special here. If your software has to work for one run "doing it right" may be a luxury. If you need your software for years to come your luxury becomes necessity.

conorgil145 10y ago

The article referenced in the blog post is also quite good: http://thenewstack.io/10x-programmer-just-jerk/ http://thenewstack.io/10x-programmer-just-jerk/

miguelrochefort 10y ago

"Right" is never fully defined, and keeps changing. Therefore, you can never do the right thing. My solution is radical, but necessary. 99.999% of code should never be written. Let's start saying no to businesses with arbitrary demands, and let's all agree on a set of standards. Only then will we have affordable and quality software.

jpgvm 10y ago
If we did that then we might actually start resembling a field of engineering. Unfortunately software is much more nebulous than structural, mechanical and other fields of engineering. There are less clear cut right and wrong things to do. Part of what gives software it's unique advantage in today's world is it's ability to change to meet evolving demands quicker than any other way of formulating solutions. As such unclear specifications are somewhat of a pillar of software engineering. However with unclear and perhaps rapidly changing specifications comes a lot of judgement calls on what to build, how to build and what are reasonable shortcuts to take. Software engineers are almost alone in this, most other professions have the "correct" way and all the ways you can do it wrong. In software there is no "correct" way and just many different ways of kinda achieving something "right".
- Fiahil 10y ago
  I guess, if it was possible to build towers and bridges at the same speed we build software projects, we would see the same level of nebulousness appear.
asimuvPR 10y ago
What do you mean exactly?
carterehsmith 10y ago
"99.999% of code should never be written" Interesting. So if you are a freelancer, you will reject 99.999% of would-be customers. Not exactly a winning formula. Or, if you work for some kind of organization, you tell them, 99.999% of the time, that the business demands are "unreasonable" and that code should not be written. That will get you fired. Either way, I am not sure where you are going with that narrative.

vmarsy 10y ago

All all the tools mentioned and similar tools are great and it would be a good idea to integrate them in the development process, but I don't think they're that useful to diminish technical debt. Technical debt to me is uncessary dependencies, anti patterns etc. The only way to prevent this is a good code review were people pay attention to such things. Ideally the code author and the reviewers have the right thinking: after checking for correctness, they ask themselves "is this code modular/reusable/easily testable/easy to debug/..." Hopefully the testing is already here, but that's in a perfect situation

Xcelerate 10y ago

> Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. Perhaps this is a true statement; however, I have no doubt that 10x programmers do exist who do not build technical debt into the application. Some people really are that good. I don't think the average person realizes exactly how good the best in the world are at what they do. For instance, I ran track for 8 years and competed in college. You don't realize exactly how insane a 12:37 5K is until you've trained as hard as you can for years and you're not even close to that time. Nor do you realize how difficult a perfect rendition of Liszt's transcendental etudes are until you've spent years trying to learn them on your own. I imagine the best programmers in the world are similar, but it would take the average programmer decades of programming before the magnitude of the skill gap becomes evident.

ljw1001 10y ago
10X programmers are unicorns. If a 5K of 12:57 was really "10X", an average runner would take just over two hours. That performance is nothing like 10X.
- bdcravens 10y ago
  I don't think that's a good analogy - a run has a very defined course, a very defined technique (you must run, not use a motorcycle), and very defined end point. Most programming problems have infinite solutions, and you're typical 1x developer can only see what they know and have experienced. To carry the analogy forward, a 10x runner might take a shortcut, use a better implement to complete the course, etc.
  - dasil003 10y ago
    Yeah a (slightly) better sporting analogy might be chess. Like chess, programming is a game of knowledge and forethought, where intelligence is an asset, but far from sufficient to elevate you without a ton of practice. However unlike chess, there is no scope or rigid definition of programming, it is as if there were as many pieces with different rules as there are possible positions on a chessboard, and furthermore that the rules of the pieces are made up themselves of subpieces all of which are programmable, and that you can essentially change everything from the behavior of the squares up to the overarching rules. Now in chess, as in programming, there are clearly some individuals who excel by orders of magnitude over beginners and even average competent players. But because of the vast scope of possibility, programming "grandmasters" will do things that no one else could have even thought of in one domain, while in unfamiliar domains they might require a good deal of study before they surpass the average journeyman practitioner. Meh, analogies suck.

xiaoma 10y ago

It's interesting how different this advice is from what some of the greatest engineering cultures have done. At Microsoft during its heyday in the 90s, it was common for people to say things like, "That's the dumbest fucking idea I've ever heard" and the behavior came straight from the top. Similarly, Steve Jobs and Jeff Bezos are well known for humiliating engineers in front of an entire room after a presentation. http://www.businessinsider.com/things-amazons-jeff-bezos-tells-employees-when-he-gets-angry-2013-10 http://www.businessinsider.com/things-amazons-jeff-bezos-tel... There's no way to prove the issue definitively either way, but I suspect this blog post suffers from the cognitive bias of confusing how the world should be with how it is. At the very least, a "no shaming" rule isn't a requirement for building a world-class engineering organization and attracting top talent.

ArkyBeagle 10y ago
I've worked for real jerks before. I don't think the economics of it work out. This being said, you learn a certain stoicism in the face of it. If you catch a real rant, a stone cold "You finished?" at the end might be in order. Don't get me wrong, I've raised my voice at people but only after they've persisted in a particular error for months, after receiving many many external reference to why it's an error. I've no interest in working for a Bezos-type because I see that as a "cult of personality". It's something people have to work around. If people are risk averse to sharing ideas, then you'll get fewer of them. Perhaps that's a good thing. But it costs very little to learn to provide feedback in a non-confrontational manner.
ovt 10y ago
I imagine how well people tolerate what they shouldn't has something to do with being Authoritarian Followers. And something maybe connected with those who glory in hazing culture. And we must grow past that kind of idiocy. If I worked for someone who treated me like that and then, decades later, I heard that they'd finally died, I'd say IT'S ABOUT FUCKING TIME! and have a little party.
- quietplatypus 10y ago
  I think I know what you're talking about when you mention Authoritarian Followers---something like abused kids who only know how to deal with situations in which they are abused, even when they grow up. The worse part is they want to have "followers" themselves as well, subconsciously, repeating the cycle. I still have many properties of Authoritarian Followerism in myself, but I'm making progress. One of the difficult parts is many people around me show blatant signs of that followerism and it's easy to get sucked back down with them. E.g., a coworker protested my protestations against our company stack ranking employees based on "quantitative" metrics, and then many months later backpedaled on his words when someone who had a more important title said the same concerns.

issa 10y ago

In my experience, the most important skill in an engineer is figuring out what to build. Someone's skill at the actual task of programming is trivial in comparison.

im_down_w_otp 10y ago

I'm pretty sure the marketplace has decided that doing things "right" isn't particularly valuable. There are places currently where you'd expect an extremely high degree of rigor to be applied to a variety of engineering and technology problems because the potential financial impact of a cluster of interrelated faults would be irreparably financially and reputationally disastrous. But instead you will often find the overwhelming culture is to instead hire legions of employees/contractors ranging from demonstrably incompetent to tacitly complicit in knowingly producing garbage just so long as that garbage can be produced on reliably unrealistic (were any amount of rigor to be applied) timelines, and where the optics of "progress" vastly outweigh the quality of releases. And while none of this would be a spoken or agreed upon culture, the set of incentives in place guarantee that results do not align with the institutional rhetoric. And as much as it pains me personally to see cultures like that (as a 1x engineer who labors naively over correctness in design and implementation)... for the most part I think the marketplace got this right. If you consider realistically that the percentage of software programmers/developers/engineers/architects who work on something truly "mission critical"/"carrier grade"/"matter of life and death" is a rounding error compared to the number which work on the next Dashboards as a Service, or Fitbits for Dogs, or next-gen tween sexting mobile platform, or just toiling away fruitlessly on shelf-ware in large directionless companies surviving on the carcasses of well-heeled dinosaurs in their "enterprise sales channels", then quite obviously doing things "right" comes along with almost no actual value other than just the ability to claim you did it that way. If building most software came with anything remotely resembling the risk and liability of building a high-rise apartment building, or a suspension bridge, or the hydraulic controls of a jetliner, then one would likely see much more common practice, conventions, and thorough auditing of software that gets created. Rather than "best practices" being outliers, they'd be the norm, and they'd be much more codified and immutable than simply the most recent blog post about scar tissue earned from a metaphorical software skyscraper collapsing into The Bay one sunny Tuesday afternoon. As an informal support of the above claim. How many among us have worked on projects which included, as a central pillar of the engineering process and culture, all the following forms of testing... unit, integration, property-based, concolic, end-to-end, chaos, regression, soak, and mutation, and have indefinitely pushed back releases until all those forms of testing could be exercised and validated? Whatever the number I'd wager a year's salary that there are more people who don't even know what most of those things are than the number which have been required to diligently do all of them. Probably by an order of magnitude. If we're talking about mythological 10x unicorns, perhaps we can start with that one?

vigilant 10y ago

The reason the debt metaphor is used for technical debt is that debt isn't necessarily a bad thing - it just something to understand and manage. Most people, when they buy a house, go into debt (e.g.: a mortgage) for the initial purchase - without that debt, they would never be able to save up the money needed to buy that house. A startup seems similar - the first goal of a startup should be to show traction and market fit before running out of runway - and if building up technical debt lets them achieve that more quickly, then that is the right thing to do. This first phase seems to be where the 10x programming would shine.

pacala 10y ago
Great point. Debt is a necessary part of bootstrapping a new project. That being said, technical debt is not a blanket excuse for violating elementary engineering precepts, shipping shoddy components full of bugs or a necessary evil part of the final product. The team must be able to be specific about the technical debt and execute a reasonable plan to repay it.
- mpbm 10y ago
  Technical debt actually isn't a great metaphor. It breaks down too quickly, as in this case. You don't have to "repay" technical debt. It's not really debt. A company only needs to build something that works. If it works in spite of violating elementary design precepts, shoddy components, bugs, and necessary evil, then it still works. The only thing that matters is the result. Investing resources into optimizing it so that it works better than necessary is merely an option, whereas getting it to work wasn't. The iron triangle includes cost and schedule in addition to performance. If it would take more money or time than you have to make it perform better, then it just won't, because you don't have that much money or time. A product that frightens the maintainers, but keeps the lights on, is a good result. Of course, you might optimize yourself into a local maximum if you're weak on strategy. That's why nearly every organization in the world has some kind of separation between "officer/executive" and "enlisted/staff" in the hierarchy. Someone needs to balance the triangle and someone needs to write code and there isn't enough time for the same person to do both.