> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management.
I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most waste I've ever seen has always come down to poor communication rather than anything actually business or technical related.
For me this outlines the caveats and pitfalls of software development and management.
There is real truth to some of the authors points showing real paths that emerge naturally.
If you're going to gaslight him by inferring anyone who is critical is an asshole, maybe you should ask yourself why you're taking the article so personally...
I worked with one person who weaponized pedantry. He thought he was educating everyone by being a complete stickler for his specialized vocabulary and would never just answer a bloody question, wasting everyone's time. He thought he was Socrates but he was the hemlock. Similar to a good project manager he was like a chain-saw: very effective, but you always want the tool pointed away from you. It also meant you really thought about whether you could get what you needed done with any other tool rather than pull out the chainsaw. Ultimately this kind of behavior is a productivity sink; forcing everyone into your rules because it'll be so much better when everyone just complies with how you need the world to be means getting worked around and giving the pedant's work to someone more pleasant to work with.
Please note: I'm not dinging people who sincerely need structure to help them function. This was a conscious choice just to be a jerk because in that person's opinion everything would be great as soon as we all thought exactly like he did.
The contagious jerks are often results of working with -10x engineers. At some point you become as such, if you don't quit the company before that. There are "bad engineers" and then there are -10x engineers, it is a real problem if the company keeps such engineers
You should try working with -10x engineers and see how your feedback is being ignored as tech debts are piling up, products are continue to under deliver and missing deadlines.
I read the post, saw this comment, then re-read it again. I did not get the impression that author was trying to be negative. I think they were just trying to write in an "edgy" style. I've seen most of the things on the list happen (at least to a degree).
On the topic of contagious jerks, my experience has been that these people often suck at engineering.
For example, a few years ago, one of the product managers was super excited to recruit an engineer they had worked with before. The engineer was talked up. A real genius. Someone who would come in and do things right. He would lead a new sibling team working on a new product. I was excited. We could use the help as we were going through hyper-growth.
The engineer seemed smart, but had a very sarcastic and negative attitude. The existing architecture was garbage. Everyone's code was terrible. Even the choice of language was wrong. While he was respectful towards me and the work I had done, I saw him put down most of the people around him. I kept my distance and let him do his thing. It wasn't my place in the organization to interfere anyway.
The end result was he drove half his team to quit, delivered an absolute disaster of a system, and then left.
I've seen versions of this play out a few times. My experience has been that the smartest people are often the nicest because they are smart enough to recognize the value in lifting everyone. I know its not always the case and I have worked with difficult people who genuinely were incredible engineers as well, but they tend not to actively put everyone around them down.
It's not 0/1 problem. Obviously being asshole for no reason is bad.
But bending over backwards for bad solutions just coz you "don't want to rock the boat" or "don't want to argue" leads to mediocre product driven by whoever happens to be least polite in the team. Tiny bit off stubborness and assholery on stuff you know is right (as in when nobody can provide actual sensible arguments for other way) can be very helpful.
Also I did worked with "toxic but brilliant" ones and honestly I vastly prefer it over nice useless people. Toxicity can be managed, uselessness can not.
What's more, the contagiousness aspect isn't the only issue here. Jerks tend to cause problems for organisations for other reasons too. Such as:
1. They scare away a lot of competent workers, since many smart and talented employees won't want to be stuck working alongside an asshole, regardless of how 'talented' they might be. And given that the best employees tend to have a plethora of options for where to work, and well... you can guess how that affects the talent remaining.
2. They discourage newer and less experienced employees from learning/improving, and instead encourage them to leave. But folks who aren't necessarily the most talented developers now can very much turn into such with the right environment and incentives, which these types of people don't provide.
There really aren't any benefits to keeping around jerks, and a whole lot more downsides than people think.
I find it's context dependent. Sometimes everyone is working hard and doing their best and someone's being a toxic jerk. Sometimes things are going badly wrong and you need someone to actually stand up and say "Hey, how come these requirements keep changing we've wasted months doing something that was totally useless" or "Hey, how come our AWS bill is $100,000, and hang on a second, why isn't anyone monitoring our AWS bill?" or "Hey, the core premise of this project turns out not to be true, maybe we should really re-evalaute rather than ploughing on".
Sometimes requirements are unclear and you just have to learn as you go. Sometimes the AWS bill is the last of your porblems. Sometimes you find out something you had assumed at the outset is wrong, but you still believe in the project. It's context dependent.
Also, it's often more difficult to be the person asking the hard questions than the person who just goes along with things.
I get the sense that this is an investor/bankroller that fancies themselves as an engineer, or a manager that has done a terrible job of hiring so far.
Why do you believe the traits and behaviors outlined in the article are mutually exclusive with being a jerk? In my experience, most of the toxic people I've worked with were toxic because they exhibited a number of these traits and were thus ineffective and using toxicity to compensate.
I'm nodding along to this list because I've been consulting with a large government department that has dozens of programmers with the effective output of maybe... two? Three at the most.
They tick just about every item on that list. Staggering inefficiencies everywhere, duplicated work, duplicated codebases, etc, etc...
The worst thing about these problems is that they compound, often exponentially or at least quadratically. Slow builds mean bug fixes take longer. Longer bug fix times means they can't all be fixed to meet deadlines. That means that they now have to be prioritised, which incurs management overheads and shuffling things around in spreadsheets. This then delays things further, which means even critical requirements (security!) get dropped on the floor.
The inevitable consequence is that things are constantly breaking in production, and everyone spends half their time fighting fires. Fires that were marked as a "low-priority" smell of smoke six months ago.
Productive staff see the writing on the wall, quit, leaving only the unproductive staff that "couldn't get a job elsewhere".
The snowball builds rapidly from here into an avalanche of badness.
> Attract bright engineers and waste their potential. Undersell the difficulty of the project to management; oversell the project’s usefulness. Tell management it’s “almost complete” until they scrap it.
People at every level of the organization, from the top-down, have done this since forever. The -10x engineer will choose a language that they're fascinated by, but have no production experience with, and then spend most of the budget building libraries that they assumed already existed in the ecosystem. "Almost complete" becomes "almost ready to start".
I think as engineers we have to realize a few things:
1. Unless you are working alone and for yourself good communications are more important than most engineers will admit. The thing is: the quality of communication does not necessarily correlate with the quantity or the duration of it. And depending what role you play, you might not need a lot of communication in order to get a clear picture, while others might need more (for you: unnecessary) communiation to get on the same page. The drummer of my band always used to say there shouldn't be that much discussion about what we are playing, which is super easy to say if you don't need to harmonically integrate with other instrumentalists.
2. Every single one of us is in danger of dialing the degree of complexity too far, or not far enough. Every single one of us is in danger of doing things a certain way because we try to make them nice, while that makes them technically unmaintainable. Code is communication as well. Communication with your collegues or yourself in the future. Good code is efficient, reliable and communicates well. Sometimes we have to sacrifice a little bit of one for the other, but clear code and e.g. efficient code should not be seen as opposites, but as a multidimensional problem to which there are solutions that work better on both fronts and solutions that suck on both fronts.
3. Context. Many engineers I have met have a hard time explaining some concept or problem in a way that it is understandable. Either they dive in way to hard and assume everybody knows what they know or they will start explaining it and get side-tracked and end up talking about something entirely else. Giving someone a clear image of where we are and then zooming in on the detail in well-sized steps is a skill I wish more people had. This skill also helps when debugging, because you will check your zoomed-out-priors first and then bifurcate the problem space as you zoom in.
The "don't rock boats" is really what can slowly destroy companies. The -nx engineers know a lot of other -nx engineers that can come onboard until the stable boat just sinks.
Sometimes things just need to fail naturally and some rando on a mission to “rock the boat” is a net negative.
Picking your fights is an important thing to learn too, throwing a fit over everything “wrong” can be terrible for everyone… even if you’re right every time.
It's not that bad engineers only socialize with other bad engineers - but rather that many naïve and inexperienced engineers are much too kind, and will try to onboard every friend or relative they know, without ever having worked with them - they're basically vouching people blindly.
This is something I've seen myself: Clueless manager hires the wrong man for the job -> wrong man is utterly clueless on how things work, what needs to be done, and flounders around for a couple of months -> wrong man decides that, hey, I know this one guy that seems to know his sh!t, let's get him onboard. Just fast-track him through the process.
Turns out the new guy is also wrong man for the job, and doesn't know what to do. So now they're two (wrong) guys doing busywork while the ship is sinking.
I love the skunkworks reference. Every time I see something like this in a 3 person startup, I just want to grab someone by the neck and tell them:
"Bro, your mobile app redesign to Flutter is not a 'skunkworks' project. Unless you are Lockheed Martin, or Boeing, and the project will approach a trillion dollars of spend, has the capability to eliminate millions of human lives, and requires 1000 security managers and 25,000 Top Secret/SCI employees you ain't doing no 'skunkworks'"
> Make undebuggable programs. Plaster layers of abstraction over everything. Write spaghetti code. Make everything sensitive to initial conditions. Avoid pure functions. Use dependencies liberally. Say “it works on my machine” whenever possible.
A lot of legacy software is like this. I wonder how many billions it costs the economy per year.
This whole thing about company/team culture is that it is random.
Even when you are at the best team, culture-wise and productivity-wise, accept that this will not last. All it takes is for 1 person to arrive/depart to ruin the culture.
Just do your best and bounce when it's time. You cannot move Mount Fuji with a teaspoon.
Got it. The -10x engineer is bad management who are in turn bad because the rest of the business is completely illiterate about anything even slightly technical.
I've seen engineers who are good candidates for -10x... The moral of this story is, of course, if people are submitting work that creates more work, you must push back against them.
Part of the issue is that intelligent people can be better at justifying work that wastes everyone's time. So if you're in a leadership position you really need to make sure people have their eyes on the prize and that they aren't padding their resume or needlessly doing tasks that worked at their previous job.
A lot of these look like Goldilocks problems, e.g.
> "Waste 400 hours of engineering on bad architecture: Give zero consideration to how your system design will evolve over time. Alternatively, drive your team obsess over architecture decisions so that they don’t have time to test their hypotheses."
A complex project with many people working on it in different teams calls for modularization and well-defined interfaces, so working out the architecture up-front does matter, and changing it down the line will have huge costs. Staged progession is the answer, probably, which is why you'd want to have a meeting where everyone agrees, "this is the architecture we're going with, now everyone go build the modularized widgets that fit into this architecture, here are the stable interfaces to build to." Screw that up and you end up with tons of wasted effort, but dithering around and never making a decision is no better.
Some of the other stuff relates to the 'build team spirit' corporate mentality which is kind of culturally variable - some people love it and some people hate it. Minimal is better, IMO.
Then there's the 'basic technical proficiency' category of problems, e.g. recompliling the entire collection of source code every time you make a lttle change because the build configuration in the makefiles is incorrect etc. That's probably the easiest category to fix, some people just have holes in their knowledge and those can be filled. Here is where the company jerk is a major liability, though - you want people who can teach others how to improve their workflows without engaging in any condescending / egomaniacal / prima donna behavior.
Most of these are either management issues or written as if the person is acting in bad faith. But there are plenty of engineers who are 1) smart 2) driven, and 3) well-meaning that still find themselves in this position
One time I found myself in this position was overseeing an infrastructure migration for scaling reasons. The goal was to have it done before we hit scaling limits, and we had a team of 2 people and a fairly complex architecture. From the start, I suspected it might be difficult to do with the current staffing, even after extensive planning, but I underestimated what the costs would be to not completing the project on time.
I was told by my manager that completing the project before hitting scaling limits was life or death for the company (it wasn’t, I know this because the sales team didn’t hit their targets and we survived). I now realize this was my manager attempting to motivate me to take on a tough project, rather than real truth. Had I pushed back harder, inquired about company financials, this would have been exposed as not true.
While we eventually ended up completing the project, we completed our largest phase of hiring while in limbo between 2 architectures. The company became disorganized, accepting large amounts of tech debt as it was tough for new hires to understand what the “correct” thing to do was, and many people ended up adding to the legacy architecture in cases where they didn’t need to. It was a mistake that likely cost millions, even tens of millions in my eyes.
The correct thing to do, of course, was just to insist that we couldn’t scale until we trained or hired more people to help. Limiting growth is often seen as unacceptable in startup culture, but IMO should be considered more often.
> To ensure developers are context-switching, recompilation should take at least 20 seconds.
I'm now wondering what languages and projects the author has worked on if they expect compilation to take less than 20 seconds. Maybe small-ish golang projects? I don't remember the last time I worked on something interesting where recompilation was always under a minute...
Delphi used to compile 200k lines in less than ten seconds. That was around year 2000, with first generation Pentium. Later it slowed down a bit, but not so much.
IIRC, C family compilers suffer from some problem with headers that makes compile time much longer than it should.
Edit: oh, and that was rebuilding the whole program from scratch, including all libraries. A little change in the current file was les than one sec. Native code, in case you're wondering.
Anything written in interpreted languages like Javascript/Typescript.
UI stuff usually has hot reloading where you get "compilation" times measured in milliseconds, and from experience restarting even a complex typescript server is a few seconds max. This applies to mobile apps as well when using React Native.
I worked hard on my previous project to achieve a 5sec build-run-test cycle for a medium-sized embedded C project (we don't have monster workstations, just some i7-10xxx/16GiB PCs).
Thinking about proper modularization, runtime code (hot-re)loading, and eliminating single-point-of-recompilation for header files goes a long way.
The gamedev industry figured this out a long time ago, see Handmade Hero's Hot reloading[0].
Also, an interactive shell (we use IPython) with all of the compiling and debugging utilities you need is easily a 5x efficiency boost, e.g. I can run `./devshell.py <NAME_OF_TARGET>`, then `run('foo', 'bar')` and the script will compile, upload, and re-execute the `foo` and `bar` modules. Makes onboarding much easier too.
A lot can be done, even in languages that compile quite slowly, to get good performance in practice. See, for instance, what one can do with bazel and build servers. A cold compile is still not going to be good, but you'll never do a cold compile, and it will be very rare to recompile something that will require changing the entire tree.
At an old job, we had files that were slow enough that we'd have them in a separate compilation unit (automatic derivation of typelcasses with multiple serialization schemes) , so if you didn't change them, you'd just be picking up the binary. And if you were changing them, you weren't changing anything else, so ultimately a very slow compilation step was never a thing.
But yes, it's a matter of investment that few companies are willing to make
the real problem is build time with the windows filesystem (in my case). switching to wsl2 you get under 20 sec. pretty easily, and most projects > 20 seconds are fixable (that is, if someone fixes it). Deploy time, on the other hand...
sigh. The 10x engineer has become tech's most toxic concepts and devs are its victims, yet we keep bringing it up constantly. Every time it's brought up it's a new variation that's either bad or good but always different than the original proposal of the BEST programmers are 10x more productive than the WORST developers from a paper in 1968. All that is come of it is devs arguing about a hypothetical programmer is and made management even more insufferable. The idea is only hurting you, quit bringing it up, when it is brought up point out it's a bad concept and move on.
I thought so until I met one. He knew what our team lead wanted before he wanted it and would already have it done, along with all of his assigned work. He would take initiative and build tools that the whole team could use and be more effective with. He had a huge impact on me.
I don't agree that writing and communicating designs, plans, and discussing problems or solutions is a waste of time. Our job isn't to blast code out and not talk to anyone (unless you're the sole developer on a project, but even then you should still write). Writing is thinking! Thinking is our job. Code is the artifact.
- Add cool new tech to projects you're working on with ten other people. Ensure only one other person knows.
- Name all your variables 'data'.
- Copy and paste everywhere. People will think they've fixed a bug, and they have, but you've got seven slightly different copies of the function that needed fixing and now there's six left.
- Take a project that's using one of those 'prettier' 'black' style tools to avoid bike-shedding discussions about linting. Change the options because you prefer different ones. Start a bike-shedding discussion about linting.
- Use multiple divs for a single circle-shaped avatar.
[+] [-] flumpcakes|2 years ago|reply
I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most waste I've ever seen has always come down to poor communication rather than anything actually business or technical related.
[+] [-] d--b|2 years ago|reply
Sure bad engineers exist, but you know what is even worse than the -10x engineer: the contagious jerk.
https://www.inc.com/jessica-stillman/studies-being-a-jerk-is...
Yep being an asshole spreads like a disease within organizations. Avoid these guys like the plague.
[+] [-] BoneZone|2 years ago|reply
For me this outlines the caveats and pitfalls of software development and management.
There is real truth to some of the authors points showing real paths that emerge naturally.
If you're going to gaslight him by inferring anyone who is critical is an asshole, maybe you should ask yourself why you're taking the article so personally...
[+] [-] technofiend|2 years ago|reply
Please note: I'm not dinging people who sincerely need structure to help them function. This was a conscious choice just to be a jerk because in that person's opinion everything would be great as soon as we all thought exactly like he did.
[+] [-] shultays|2 years ago|reply
You should try working with -10x engineers and see how your feedback is being ignored as tech debts are piling up, products are continue to under deliver and missing deadlines.
[+] [-] naillo|2 years ago|reply
[+] [-] surprisetalk|2 years ago|reply
I don't want to empower jerks.
Anything particular I should change? Or is the structure of the essay too cynical overall?
[+] [-] coldtea|2 years ago|reply
Yeah, or as it's scientifically called: "realism"
[+] [-] time0ut|2 years ago|reply
On the topic of contagious jerks, my experience has been that these people often suck at engineering.
For example, a few years ago, one of the product managers was super excited to recruit an engineer they had worked with before. The engineer was talked up. A real genius. Someone who would come in and do things right. He would lead a new sibling team working on a new product. I was excited. We could use the help as we were going through hyper-growth.
The engineer seemed smart, but had a very sarcastic and negative attitude. The existing architecture was garbage. Everyone's code was terrible. Even the choice of language was wrong. While he was respectful towards me and the work I had done, I saw him put down most of the people around him. I kept my distance and let him do his thing. It wasn't my place in the organization to interfere anyway.
The end result was he drove half his team to quit, delivered an absolute disaster of a system, and then left.
I've seen versions of this play out a few times. My experience has been that the smartest people are often the nicest because they are smart enough to recognize the value in lifting everyone. I know its not always the case and I have worked with difficult people who genuinely were incredible engineers as well, but they tend not to actively put everyone around them down.
[+] [-] ilyt|2 years ago|reply
But bending over backwards for bad solutions just coz you "don't want to rock the boat" or "don't want to argue" leads to mediocre product driven by whoever happens to be least polite in the team. Tiny bit off stubborness and assholery on stuff you know is right (as in when nobody can provide actual sensible arguments for other way) can be very helpful.
Also I did worked with "toxic but brilliant" ones and honestly I vastly prefer it over nice useless people. Toxicity can be managed, uselessness can not.
[+] [-] CM30|2 years ago|reply
1. They scare away a lot of competent workers, since many smart and talented employees won't want to be stuck working alongside an asshole, regardless of how 'talented' they might be. And given that the best employees tend to have a plethora of options for where to work, and well... you can guess how that affects the talent remaining.
2. They discourage newer and less experienced employees from learning/improving, and instead encourage them to leave. But folks who aren't necessarily the most talented developers now can very much turn into such with the right environment and incentives, which these types of people don't provide.
There really aren't any benefits to keeping around jerks, and a whole lot more downsides than people think.
[+] [-] tasubotadas|2 years ago|reply
[+] [-] SilverBirch|2 years ago|reply
Sometimes requirements are unclear and you just have to learn as you go. Sometimes the AWS bill is the last of your porblems. Sometimes you find out something you had assumed at the outset is wrong, but you still believe in the project. It's context dependent.
Also, it's often more difficult to be the person asking the hard questions than the person who just goes along with things.
[+] [-] brodouevencode|2 years ago|reply
[+] [-] d23|2 years ago|reply
[+] [-] peoplefromibiza|2 years ago|reply
the first one to denounce it encourages other colleagues to speak up, like it happened with the metoo movement.
http://www.quickmeme.com/img/13/13d4f6f146baa91dbc0946651ca0...
[+] [-] infamouscow|2 years ago|reply
The study you linked assumes the actors are not stupid.
[+] [-] rvba|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] goodpoint|2 years ago|reply
EDIT: ...as proven by the rain of downvotes...
[+] [-] jiggawatts|2 years ago|reply
They tick just about every item on that list. Staggering inefficiencies everywhere, duplicated work, duplicated codebases, etc, etc...
The worst thing about these problems is that they compound, often exponentially or at least quadratically. Slow builds mean bug fixes take longer. Longer bug fix times means they can't all be fixed to meet deadlines. That means that they now have to be prioritised, which incurs management overheads and shuffling things around in spreadsheets. This then delays things further, which means even critical requirements (security!) get dropped on the floor.
The inevitable consequence is that things are constantly breaking in production, and everyone spends half their time fighting fires. Fires that were marked as a "low-priority" smell of smoke six months ago.
Productive staff see the writing on the wall, quit, leaving only the unproductive staff that "couldn't get a job elsewhere".
The snowball builds rapidly from here into an avalanche of badness.
[+] [-] Dowwie|2 years ago|reply
People at every level of the organization, from the top-down, have done this since forever. The -10x engineer will choose a language that they're fascinated by, but have no production experience with, and then spend most of the budget building libraries that they assumed already existed in the ecosystem. "Almost complete" becomes "almost ready to start".
[+] [-] atoav|2 years ago|reply
1. Unless you are working alone and for yourself good communications are more important than most engineers will admit. The thing is: the quality of communication does not necessarily correlate with the quantity or the duration of it. And depending what role you play, you might not need a lot of communication in order to get a clear picture, while others might need more (for you: unnecessary) communiation to get on the same page. The drummer of my band always used to say there shouldn't be that much discussion about what we are playing, which is super easy to say if you don't need to harmonically integrate with other instrumentalists.
2. Every single one of us is in danger of dialing the degree of complexity too far, or not far enough. Every single one of us is in danger of doing things a certain way because we try to make them nice, while that makes them technically unmaintainable. Code is communication as well. Communication with your collegues or yourself in the future. Good code is efficient, reliable and communicates well. Sometimes we have to sacrifice a little bit of one for the other, but clear code and e.g. efficient code should not be seen as opposites, but as a multidimensional problem to which there are solutions that work better on both fronts and solutions that suck on both fronts.
3. Context. Many engineers I have met have a hard time explaining some concept or problem in a way that it is understandable. Either they dive in way to hard and assume everybody knows what they know or they will start explaining it and get side-tracked and end up talking about something entirely else. Giving someone a clear image of where we are and then zooming in on the detail in well-sized steps is a skill I wish more people had. This skill also helps when debugging, because you will check your zoomed-out-priors first and then bifurcate the problem space as you zoom in.
[+] [-] fvdessen|2 years ago|reply
[+] [-] Manjuuu|2 years ago|reply
[+] [-] duxup|2 years ago|reply
Picking your fights is an important thing to learn too, throwing a fit over everything “wrong” can be terrible for everyone… even if you’re right every time.
[+] [-] HPsquared|2 years ago|reply
[+] [-] TrackerFF|2 years ago|reply
This is something I've seen myself: Clueless manager hires the wrong man for the job -> wrong man is utterly clueless on how things work, what needs to be done, and flounders around for a couple of months -> wrong man decides that, hey, I know this one guy that seems to know his sh!t, let's get him onboard. Just fast-track him through the process.
Turns out the new guy is also wrong man for the job, and doesn't know what to do. So now they're two (wrong) guys doing busywork while the ship is sinking.
[+] [-] blantonl|2 years ago|reply
"Bro, your mobile app redesign to Flutter is not a 'skunkworks' project. Unless you are Lockheed Martin, or Boeing, and the project will approach a trillion dollars of spend, has the capability to eliminate millions of human lives, and requires 1000 security managers and 25,000 Top Secret/SCI employees you ain't doing no 'skunkworks'"
Cracks me up.
[+] [-] mkl95|2 years ago|reply
A lot of legacy software is like this. I wonder how many billions it costs the economy per year.
[+] [-] dividedbyzero|2 years ago|reply
[+] [-] didip|2 years ago|reply
Even when you are at the best team, culture-wise and productivity-wise, accept that this will not last. All it takes is for 1 person to arrive/depart to ruin the culture.
Just do your best and bounce when it's time. You cannot move Mount Fuji with a teaspoon.
[+] [-] sublinear|2 years ago|reply
[+] [-] havblue|2 years ago|reply
Part of the issue is that intelligent people can be better at justifying work that wastes everyone's time. So if you're in a leadership position you really need to make sure people have their eyes on the prize and that they aren't padding their resume or needlessly doing tasks that worked at their previous job.
[+] [-] photochemsyn|2 years ago|reply
> "Waste 400 hours of engineering on bad architecture: Give zero consideration to how your system design will evolve over time. Alternatively, drive your team obsess over architecture decisions so that they don’t have time to test their hypotheses."
A complex project with many people working on it in different teams calls for modularization and well-defined interfaces, so working out the architecture up-front does matter, and changing it down the line will have huge costs. Staged progession is the answer, probably, which is why you'd want to have a meeting where everyone agrees, "this is the architecture we're going with, now everyone go build the modularized widgets that fit into this architecture, here are the stable interfaces to build to." Screw that up and you end up with tons of wasted effort, but dithering around and never making a decision is no better.
Some of the other stuff relates to the 'build team spirit' corporate mentality which is kind of culturally variable - some people love it and some people hate it. Minimal is better, IMO.
Then there's the 'basic technical proficiency' category of problems, e.g. recompliling the entire collection of source code every time you make a lttle change because the build configuration in the makefiles is incorrect etc. That's probably the easiest category to fix, some people just have holes in their knowledge and those can be filled. Here is where the company jerk is a major liability, though - you want people who can teach others how to improve their workflows without engaging in any condescending / egomaniacal / prima donna behavior.
[+] [-] yunwal|2 years ago|reply
One time I found myself in this position was overseeing an infrastructure migration for scaling reasons. The goal was to have it done before we hit scaling limits, and we had a team of 2 people and a fairly complex architecture. From the start, I suspected it might be difficult to do with the current staffing, even after extensive planning, but I underestimated what the costs would be to not completing the project on time.
I was told by my manager that completing the project before hitting scaling limits was life or death for the company (it wasn’t, I know this because the sales team didn’t hit their targets and we survived). I now realize this was my manager attempting to motivate me to take on a tough project, rather than real truth. Had I pushed back harder, inquired about company financials, this would have been exposed as not true.
While we eventually ended up completing the project, we completed our largest phase of hiring while in limbo between 2 architectures. The company became disorganized, accepting large amounts of tech debt as it was tough for new hires to understand what the “correct” thing to do was, and many people ended up adding to the legacy architecture in cases where they didn’t need to. It was a mistake that likely cost millions, even tens of millions in my eyes.
The correct thing to do, of course, was just to insist that we couldn’t scale until we trained or hired more people to help. Limiting growth is often seen as unacceptable in startup culture, but IMO should be considered more often.
[+] [-] biosboiii|2 years ago|reply
[+] [-] tetromino_|2 years ago|reply
I'm now wondering what languages and projects the author has worked on if they expect compilation to take less than 20 seconds. Maybe small-ish golang projects? I don't remember the last time I worked on something interesting where recompilation was always under a minute...
[+] [-] narag|2 years ago|reply
IIRC, C family compilers suffer from some problem with headers that makes compile time much longer than it should.
Edit: oh, and that was rebuilding the whole program from scratch, including all libraries. A little change in the current file was les than one sec. Native code, in case you're wondering.
[+] [-] enlyth|2 years ago|reply
[+] [-] wazzaps|2 years ago|reply
Thinking about proper modularization, runtime code (hot-re)loading, and eliminating single-point-of-recompilation for header files goes a long way.
The gamedev industry figured this out a long time ago, see Handmade Hero's Hot reloading[0].
Also, an interactive shell (we use IPython) with all of the compiling and debugging utilities you need is easily a 5x efficiency boost, e.g. I can run `./devshell.py <NAME_OF_TARGET>`, then `run('foo', 'bar')` and the script will compile, upload, and re-execute the `foo` and `bar` modules. Makes onboarding much easier too.
[0]: https://www.youtube.com/watch?v=Pax5jIz6m_Q
[+] [-] hibikir|2 years ago|reply
At an old job, we had files that were slow enough that we'd have them in a separate compilation unit (automatic derivation of typelcasses with multiple serialization schemes) , so if you didn't change them, you'd just be picking up the binary. And if you were changing them, you weren't changing anything else, so ultimately a very slow compilation step was never a thing.
But yes, it's a matter of investment that few companies are willing to make
[+] [-] hardware2win|2 years ago|reply
So you either worked on the biggest codebases in the world
Or youre doing CPP :)
[+] [-] flippinburgers|2 years ago|reply
[+] [-] truculent|2 years ago|reply
[+] [-] fedeb95|2 years ago|reply
[+] [-] lispisok|2 years ago|reply
[+] [-] 2OEH8eoCRo0|2 years ago|reply
[+] [-] agentultra|2 years ago|reply
[+] [-] nailer|2 years ago|reply
- Name all your variables 'data'.
- Copy and paste everywhere. People will think they've fixed a bug, and they have, but you've got seven slightly different copies of the function that needed fixing and now there's six left.
- Take a project that's using one of those 'prettier' 'black' style tools to avoid bike-shedding discussions about linting. Change the options because you prefer different ones. Start a bike-shedding discussion about linting.
- Use multiple divs for a single circle-shaped avatar.