How to be a -10x Engineer
taylor.town
taylor.town
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.
* The next developer to pick up the task where you left off
* Your technical lead asking for update
* Your manager needing an update for his manager
* Product management wanting to know where we are on some feature
* End users wanting to know when the bug fix / feature they asked for will be in their hands
Everywhere I have worked, we had multiple apps/ticketing systems/etc all trying to roll up / slice & dice data to get to the above.
In the end it just turns into talking to management pinging the next level below them for adhoc status.
Why? Because product is too ignorant to open Jira nor maintain status themselves. Because management above the line manager level is apparently incapable of opening Jira either, let alone 2-3 levels up. Also no one wants to hire real project managers anymore to maintain all the different views & send the weekly updates they demand to receive.
Fixing this from the bottom up is better accomplished via updating ones resume & LinkedIn profile.
But very little detail on how one was technically to do the task, or time spent discussing technical options & tradeoffs.
I would say that rather depends on how much of it you do.
For example, I went through a dozen tickets this morning and 96% of my time was spent either writing updates or doing the work the tickets were talking about. 4% probably went to reading the ticket itself and placing it in the correct place after updates/work. That 4% means meetings later will flow faster, and I don't have to remember or write down details and statuses of things somewhere else.
Are people really wasting time on 'ticket management' that isn't as I've described?
Edit:
I've spent some time thinking about this, and despite being the org owner for our companies Azure DevOps instance I'm actually firmly in the 'Ops' camp of Ops<->DevOps<->Dev. My job is mainly Ops and I do some DevOps/SRE work on the side as the pragmatic-infrastructure-guy. I often see lots of nonsense done in the Developer camp. I think why I don't see the downsides of tickets is because I come from the background where tickets are more Help Centre-like. It's just pieces of work that needs doing or people need help with. If the help centre started arguing about if something is 'high' or 'critical' or spent 50% of their time just 'managing tickets' then they would flat-out just get fired. I guess that's the cultural difference between HC/Ops and 'Dev' that I wasn't really seeing before.
Inverting the priority would mean that you never update tickets until you're done fixing the problem. That might be possible in small organisations or for small problems. Everywhere else, it's necessary to provide updates from time to time before the problem is solved.
Given that, if your tasks are taking long enough that any but very-rare outliers span more than a couple status updates (which shouldn't be needed more than about weekly, under normal circumstances) then your tasks are too big or you've got some serious process issues making everything take far longer than it should.
Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!
Right, that's why I specified "normal" and "ordinary" tasks. Outages are another matter.
> Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!
Devs aren't in the ticketing system all day. They close it because they're all bloated as hell and eat system resources like mad, only opening it when strictly necessary, which then takes forever. They take longer to navigate it than you do, because they're not in it all day. They dread it because ticket workflows are often convoluted and hard to understand for anyone who's not in the ticketing system all day, and because they're all designed in such a way that it's weirdly-easy to accidentally press a button or drag something and mess things up in ways that can be tricky to fix or even to understand what's happened, sometimes without even noticing one has done that—it usually feels like trying to collaborate by using the PM's RDP-shared Windows desktop, covered with directories and text files arranged just so.
It is not the "easy way" to them, it's easy for you, and only you—otherwise, they'd use it! If your devs are any good, I guarantee they're communicating a lot, just not where you want them to, because it is not easy for them. Slack, email, git logs, PRs, quite possibly a shadow-ticketing system that's not a resource-hogging, confusing pile of crap in really pathological cases (probably the one attached to any Web-attached source management system you're using)
I agree that status needs to be communicated, but if that's more than about weekly under normal circumstances then it's because someone's screwing up, and it's worth remembering that your "easy" as someone who's in Jira (or whatever) all day isn't someone else's "easy".
Their "easy" would be you letting them use a ticket system they find actually-usable, and then reading that and translating anything that's happened there, into the one that you like but that doesn't work well for them. Or just figure out a way to use the one they like—you're one person, they're several.
[EDIT] It's also worth considering that those kinds of high-visibility-to-managers systems are always going to be a bit bullshitty. People will omit things or even lie on them at higher rates than they will on purely-internal communication tools, which is part of why people don't like to use them for their actually important communication within a team. Letting the team communicate where they like and then translating that into Manager in the high-visibility system will get you more-accurate information, and you can decide what to do with it.
That's what one has sev/incident response procedures for. Put everyone in the entire management chain on a conference call with execs/comms/legal for as long as it takes - and make damn sure the line manager is shielding the actual engineers from this process so they have time to fix the bug.
>spending the time to prioritize my work before starting my work and/or discussing the same with my team
And in the past, I did regretted opening unnecessary discussions quite a few times. I learned not to do it, because it ended in endless bike shedding or conflicts and there were no special gained insights. Turns out, I can do trivial decisions by myself.
Calling "deciding on how to spend your time" a waste of time seems a misnomer.
One project manager in our company started to actually use it for prioritization, the higher the priority the sooner it was done. Soon after, literally everything ended to labeled critical.
A useful priority scheme might be, insert the ticket in the list of open tickets by urgency and importance. Something like that, that you can actually make arguments about and compare.
We start out with some sensible definition of priority for bugs: P3 = nice-to-have, P2 = low-priority-but-ship-blocking, P1 = emergency-fix-this-now. Bug intake goes on for a while under this system. Some bug filers don't feel their P3 or P2 bugs are getting worked on, so they "promote" those bugs to P2 and P1. That'll show those engineers my bug is important! Now we seem to have more and more P1 emergencies going on, and the team is struggling to just get through those. Nobody knows which ones are actual emergencies, and which ones are just "somebody being passionate about a bug".
Soon, we get an actual pants-on-fire production emergency. This emergency is more urgent than any P1, so we call it P0! Now we finally have a way to mark real emergencies, because the bug database is now overflowing with P1s. Soon people realize they can deem their favorite bugs as really-really-important, so they promote them to P0. Eventually, the database is now overflowing with P0s, and nobody knows what's really urgent. Then another real pants-on-fire production emergency happens...
1) Allow developers to change the priority, i.e. downgrade P0 to P1 or P2, with all subscribers notified. Optionally, always downgrade to the lowest possible priority.
2) Shame people for inappropriately using P0. After a few strikes, remove their ability to do so.
If priority does matter, then why "waste"? Lets say you get rid of tickets.. then your statement becomes:
"You've ever wasted a few minutes on whether a bug you found is worth mentioning in release notes? Or if it truly should cause revert of deployment?"
When said this way, doesn't seem like "waste" to me, rather a regular part of the job. If the person working the bug doesn't know how bad it is, then who does?
Because when you have a ticket priority system, there is often someone external who cares deeply about ticket priority. And reporting requirements around ticket priority. And metrics about ticket priority over time.
If you've never been pulled into a meeting with Comms and Legal to discuss retoractively whether a (completed) ticket should have been labelled High or Severe... count yourself lucky
Wait until they start adding additional categories like critical blocker, high blocker, severe blocker, exceptionally severe blocker, etc. etc.
I don't find that a Jira ticket takes more than 2 minutes to write though, so maybe there's a difference in terms of number of mandatory fields.
I mean, that ticket was messing so hard the tech debt statistics! Or so that claimed the PM.
I sat on a team with 6+ hours per week of full-team, in a room, jira ticket creation/reviewing/sizing/prioritizing. So thats 15% overhead right off the top.
This of course was not the only time we spent interacting with tickets, as we then had daily standup, random "check-ins" from product/management on ticket status, and of course actually picking, updating, and closing our own tickets throughout the sprint.
Easily spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it.
But.
How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one?
15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity.
It doesn’t have to be Jira backlog grooming, sure. But it has to happen.
If the developers aren’t spending their time doing this, who is?
How much value do you get from putting 20 engineers in a conference room for 2 hours, 2-3 times per week? What if this is mostly just a head strong manager who enjoy monologuing his captive audience team?
Note I said "spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it" This doesn't really help prevent building things that don't fit together at all. It barely allows you to surface technical dependencies and order of operations.
15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway
Yes, that's the point, that after each week (or two) of work, we've learned more and the plan already is outdated and needs to change.
> inputs likely aren't changing with that frequency
In my experience, they absolutely are unless you're building the simplest CRUD app that's identical to one you've built before. The inputs are less often changes from external stakeholders, and more often tasks that are turning out to be more difficult than hoped.
> and you aren't going to be able to pull in all the other stakeholders that often anyway
Of course you are. It's the PM's job to gather the new inputs, go check in with relevant stakeholders (takes a day or two at most), update or re-confirm their priorities, and then make the updated decisions for the next sprint.
In my experience, 15% of time spent each week on planning is about right. It doesn't maximize the productivity of each person coding, but it hugely maximizes the productivity of the whole team in delivering a valuable end result.
What else do you want us to do for 4-6 hours/week? Write poetry?
Eventually every ticket just gets sized "medium-big", and people keep their heads down with mouths closed.
Much could be accomplished more efficiently by getting product, management, and 1-2 seniors in a room for 30min to actually decide what/if plans have changed & cascade the changes accordingly.
99 times out of 100, the plan didn't change because something raised from the bottom, but because management has changed direction or users have asked for something new. Why subject 95% of the team to hour long monologues?
15% seems very excessive. Almost a whole day a week and two days lost of deep work. Try to aim for 1.5%. Do as much of the planning as possible without a meeting.
How do people think Apple develops completely new product lines like the iPhone, iPad, watch, etc.
There's a lot more up front planning (and yes .. of course, course corrections) than a lot of agile advocates want to admit.
Most agile hyped up senior management I've met just use it as an excuse to be derelict in their ability to plan anything.
As I said, re-planning is more often than not needed because of technical challenges developers are running into. If one person is going to take 4 weeks to deliver something instead of the expected 2 days, lots of things may have to be rejiggered.
But also, yes even "real product driven company with a mature products" are changing plans every 1-2 weeks. Because each new incremental feature is a little project of its own. I never said plans get "upended" but they absolutely need to get re-adjusted ever 1-2 weeks based on both dev input and product/user reaction.
If you want to talk about the iPhone, just look up the history of how the software keyboard was developed. Talk about rapid prototyping and upending plans!
They absolutely plan where they want to be in 3-6 months -- they're generally quarterly OKR's -- but the only way they consistently achieve their targets is with weekly or biweekly readjustments.
The higher you go, the less agile it gets, because that's a horrible way to develop software, or any high-skill professional service or product.
I don’t know how you can get a team of developers to productively spend 39 hours and 24 minutes of keyboard time productively coding in the same direction with only 36 minutes of discussion.
It's the lesser tier, often non-tech companies doing this kind of micromanagement.
It’s an option, I guess… let us know how it works out for you.
In a 20+ person dev team with a lot of juniors, the team is not "coming up with a plan" or "deciding if its still working" so much as product/tech lead/a couple seniors who have zones of responsibility are handing one down. The two hours spent in the room is agile kayfabe.
"Get everyone in a room and hash it out for 2 hours" is maybe a model that works at team size of 5, senior, empowered engineers, but it is not something that works at large scales.
Obviously you don't need to pull all the junior eng offsite for a whole month, but the engineering leads + PMs + engineering management end up there. And obviously there's also ongoing prioritisation happening between leads/PM/management throughout the year - but that doesn't require pulling the whole team every week.
Senior management thinks they know where they want to be in 3 years, but there is no cascading multi-quarter, let alone multi-year planning of the projects & steps to get there.
I've even been in orgs where someone senior is trying to make very very large org & tech changes, and really can't be bothered to put the big building block steps to get from here to there. As it turns out, they never get "there".
Somehow they know enough to bring in project managers for big concrete things like "retire a datacenter" and go all out with MS Project, GANTT, etc.
However when it comes to software changes like "split an on-prem Java monolith into a fleet of python micro services in the cloud" ... it's all iterative vibes the whole way.
The promise of "agile" is, IIRC, faster turnaround and iterative development. Yes, the 'wrong' thing is expensive. Getting something basic in someone's hands in 2-3 days to get some feedback is usually more productive than days of figma then 'sign off' then work work work then putting it in hands and getting back "this is wrong" (missing data, etc). Sometimes those things can be found in 'design-only' sessions, but I've rarely seen it happen where lots is found there, then things are implemented perfectly afterwards not requiring any further changes.
Much depends on the size/scope of the work, and I don't think there's one-size that fits all, but the ticketization of work process as teams grow pushes towards "one true way", which then seems to paper over a lot of cracks that don't easily show up in burndown charts.
That 15 or 30% might be the time ultimately taken on thinking/planning/etc of a specific issue, but too often it seems there's an idea of doing more up front "gets it done" and the notion of fast feedback/iteration cycles is glossed over, and you're expected to "get it done" - "all the planning was already done".
When doing dev-type work, I always end up needing to iterate with endusers/stakeholders, and there's little 'up front' that could have been planned to avoid some of that. It may be the nature of the people/teams I've worked with, though.
The more people in the room, the fewer participate, the fewer decisions get made, the more gets punted to the next time 20 people are in the room again in 3 days.
The promise of agile is working software.
Iterative development is a how, not a what.
i understand your point, but also think 'agile' is at least as much of a 'how' as much as a 'what', especially over the last 5 years or so.
"agile" itself would seem to be a 'how'. "agile software development" as a phrase is describing - at least too many folks - 'how' the software development will be carried out.
but... it's also a massive amount of hair splitting it seems.
Keep in mind that in most "jira-oriented" places (or probably all of them), that task isn't attributed to developers at all.
If you are doing this and development, like a healthy place, yes, 30% of the time evaluating your work sounds sane. But that evaluation time must not be interleaved with development time at all. Any interleaving will destroy the value of both tasks.
But in companies that are good at engineering management, you will often find:
- weekly planning sessions
- daily standups
- work ticketing and backlog systems (sometimes Atlassian ones!)
- prioritization discussions
So I would suggest that anyone who assumes that those activities correlate with bad engineering management, is falling into a base rate fallacy.
P(is badly managed | Jira) is high, but that’s because P(is badly managed | tech company) is high.
There are a LOT of Professional Scrum Masters and Product Managers who want to constantly review the state of tickets, make update/status comments and communicate simple questions and answers via the ticket system.
Did you mean 'x'? Yes, I meant 'x'.
Our slack bot channel exploded when we hired a new Product Manager who communicated strictly via ticket updates, literally dozens of alerts per day. They got upset when they found out every single developer had unsubscribed from all the ticket channels because of the noise.
How long do your legs need to be? Long enough to reach the floor.
Does any of your manager, Product Manager, Project Manager, skip level, or teammates create unneeded communication overhead asking what the status of something is and when it will be done? A planning tool should communicate that.
Are deadlines being missed or visibility into what is actually being done missing? Planning tools should help with estimation and revealing how much complex work is being done.
In a lot of ways these tools are not going to make the work faster, but instead make it so that the human side is appeased. It reduces anxiety of managers, it creates an understandable evidence of work (most non-technical folks cannot tell the difference between a good and great implementation just by observing the app, but they can understand a ticket that explains a refactor). It drives alignment, communication, and buy in.
The fastest a developer can go is alone in a dark room with no interruptions. But that doesn't scale. Even if that engineer is a 10x engineer, you still need a different system when you want 11x development. That's when planning, communication, coordination, allocation etc. all come into play.
Consider "The Bar team wants to know about our new Foo architecture" vs "The Bar team needs a 30 minute presentation on our new Foo architecture". Does the Bar team actually need a presentation, and could it be a live demo? Do they just need better documentation? Are they building an integration, and would someone from your team working with them for a week unblock them in a way a presentation wouldn't? Could this be a ten minute call between you and the one engineer who needs a hand?
Good and experienced engineers do their best work on open-ended tasks. This is as true of communication as it is solo work. Artificially dictating the solution without understanding the problem limits them.
I don't think that's true.
E.g. diagrams are made, once, because of an audit, instead of made iteratively as the software changes.
Or someone says, "If they want to know, they can just talk to me. You know, have a conversation?"
Writing is nature's way of letting you know how sloppy your thinking is.
Too many dysfunctional teams have a culture where engineers make a 1 hour presentation at the end of a multi-week project, upload the ppt and recording somewhere and call it a wrap, without writing a word of searchable and version-controlled documentation.
Do you spend more time wrangling over the ticket content or the format? Do you spend more time discussing context & requirements, or story points? Etc
Off the top of my head these are the most common two "negative engineer" behaviors I have seen
1) Biggest one: an engineer who is not experienced at architecting complex systems, goes and architects one when complexity was not required in the first place. This is the key to never shipping and destroying entire companies.
2) Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable (always by others, often by themselves as well). This is the key to your product dying a slow death over several years.
There are negative engineers doing this stuff ALL. THE. TIME. EVERYWHERE. Despite unquantifiable volumes of both ink and blood spilled trying to prevent them.
Had worked someplace for a short stint. There was a guy who'd started a couple months before I did. His work was 'revolutionary' and 'groundbreaking' - he'd been trying to build some sort of AOP-style PHP system - PHP4, mind you - without any extensions or internals work. It was just 'program this way' - undocumented patterns that encouraged copy/paste to half-way almost get you something usable (except, not really). "Build a form to take a few fields input and store in a database" example took days to develop, because... he was just winging it. Session management? nope - we'll need to roll our own, and that'll take a few weeks.
About half the team (20ish folks) were enraptured by this guy. Someone rambled about great this guy was, said something along the lines of "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it? that's where we're at, and it's just so awesome - I can't wait to learn more!"
This guy saying that was, at the time, like... the #2 guy on the team, had been there for years, and was the defacto 'team lead' for that work, and he was taken in by a huckster. The aop guy was there for about 10 months, then left abruptly - left on a friday, sent an email on monday with "i resign, i got another job". somehow, some folks were "shocked" at his "unprofessionalism". The entire tenure had been unprofessional, but few cared to label it that.
You're so good and smart that you built something we all need to use, but you can't explain it (let alone why it's good/better), everyone else plainly admits they don't understand much about it, and use the lack of understanding as evidence that they're so bad this must be genius-level work. Insane...
Richard Feynman was certainly a genius and he was well-known for his ability to explain complex topics in ways laypeople could grasp.
*I'm skeptical of any quote attributed to Einstein, but Goodreads said it's by him.
Having used the product (which would not-infrequently manage to make keyboard input lag by full seconds on strong hardware, ate hundreds of megabytes of ram and tons of processor cycles while idle—even worse than your average webshit "app") and putting 2 and 2 together, I'm pretty sure I could have written a list of things they'd failed to take into account, and reasons the results were so poor. It was a fun read thanks to all the details, like "oh, that's why this is so awful, I see exactly what's wrong now".
[EDIT] Though to be fair—and why I hesitated to name them—I haven't used their product in four or five years, and it may be much better now. Looks like the framework they created is called Luna.
We fired our top talent. Best decision we ever made. - https://www.freecodecamp.org/news/we-fired-our-top-talent-be... ( https://news.ycombinator.com/item?id=15474893 125 comments; https://news.ycombinator.com/item?id=32211953 30 comments)
> “You will never be able to understand any of what I’ve created. I am Albert F**ing Einstein and you are all monkeys scrabbling in the dirt.”
> And so our resident genius, our Dr. Jekyll, explosively completed his transformation into Mr. Hyde.
> He declared this in front of the product design team, developers, management, and pre-launch customers. One of our project sponsors had the temerity to ask when the problem crippling our product would be fixed.
And then follow up:
A team reborn after the fiery departure of its misanthropic guru - https://blog.solha.co/life-after-rick-our-team-reborn-after-...
Amazing how much of this resonates with behaviors I've seen over the past few years.
There is also the type of "genius" who creates an overcomplicated framework as a foundation for a new project, and then leaves the implementation details to lesser minds trying to understand his work, while he moves to start another new project. He is always too busy working on a new project, doesn't have time to answer questions about the old ones. (The problem is sometimes solved by gradually removing his code. In extreme case, the library remains included, to avoid a political conflict, but the code is actually never called.)
Ah yes, if the wrong people become aware that the code is never called, better to claim that it happened as too many people had their hand in the pot, and hey, the code is still working, and the tests are passing, so you didn't realize anything was wrong, rather than ruffle feathers and say you didn't want to touch the "genius" code because it was stuck up its own ass.
I've come to think it's the biggest existential risk to doing Haskell in industry - it's red meat to org-chart climbing sharks. And the people who tend to be willing to learn and do FP in prod tend to not be politically-minded (usually due to strong principles and values), making them even weaker to these attacks.
A significant part of choosing a technology is economics of people available to hire. Who can work with that technology 5 years later, when original authors will be long gone.
Is it really cheaper to rewrite an entire working system (that took a year+ to build in the first place) than to just learn something new? I have learned a new language in order to inherit a working, hardened, well-made system before. But I am finding for certain senior engineers, the answer to "can I learn a new language" is a resounding no. The cost is infinite, so of course it's cheaper to rewrite. Plus they are incentivized to rewrite thanks to political reasons (i.e. it's a great way to get promoted).
The last time it happened, I was lucky enough to be accidentally shielded from accountability due to the organizational quagmire that resulted from the team blowing up. I basically got to do nothing for a year and make $200k. And I got to be less than useful to the principal who made the powerplay (not -10x level but I did get to spend time maintaining the existing FP system due to it having a single production consumer left). That dude did not like that I never turned my camera on. My manager also seemed pretty checked-out, so that was extra buffer.
So to summarize, I'll say that it's easy to have be prescient when you make self-fulfilling prophecies. That's one skill I've learned from senior management over the years.
I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.
Also it's not hard to hire Haskellers or Haskell-adjacent devs. Haskell in fact makes you stand out. Those sorts of people don't need months. I've seen people new to Haskell make their first commits within a week. And they weren't geniuses or anything. But they also didn't have an attitude about it.
Seriously, what important industrial problems does it solve? Explain it to me like to a manager you met in an elevator. If you say e.g. lower bug rate, then be prepared to show some evidence (and no, please don't compare it to Python or other dynamic languages).
But I will say that bugs in Haskell tend to be easier to diagnose (helpful at 2am) and aren't usually bad (although they can be). I have debugged Other People's Code while on-call in Haskell way easier than any other language.
And finally, the vast majority of bugs can be prevented or curbed by the type system. I find every time a Haskell company runs into a nasty bug or annoying issue, libraries that make use of the type system are made that reduce or remove that class of bug entirely. This sounds like you can do it in every language, but really what can be made a "library" in Haskell dwarfs what you can reasonably library-ify in most other languages.
Now, I can't give quantitative evidence of this because I don't even know how I would begin to measure it. But these qualities are definitely a big reason why I don't even listen to job offers that aren't Haskell anymore (going on 10 years of that soon) and I have and will promptly quit a job if the company moves off Haskell.
And then you lose 50k whenever the app crashes in production because someone forgot a nil/err check and your tests didn't catch it. Or you pay extra 50k whenever the whole team needs to spend a week on finding a race condition caused by someone accidentally mutating a shared slice, 20 layers below the place the corruption was seen for the first time. Or you spend extra 50k over the year for fixing all the resource leaks caused by missing defers. Or you spend 50x50k to rewrite everything in a more performant stack because of GC pauses (Discord) ;).
There are multiple ways a project can fail or add unexpected costs, and likely there's no silver bullet. There are trade-offs.
And, btw, as for simplicity, there are dozens of languages easier to learn than Go. E.g. scratch, basic, brainfuck. Why not use them? ;)
Simplicity of a language has it costs. Programs written in simpler languages tend to be more complex to compensate for lower expressive power.
Yeah, but if the stack was something common then it still wouldn't be as big a problem.
It was only when a drive-by principal engineer got wind of it that there were problems. "We don't use Haskell here" was literally the only argument for rewriting it. Nobody left before then. We were hiring people fine. The problems you are FUDing around didn't exist.
In fact, the rewrite was so slow and off-target that I had to maintain the Haskell project through a peak season with a skeleton crew of two other people who didn't leave. And we didn't even have an outage - I didn't even get paged! The project got to make the company millions of dollars yet again.
When the rewrite finally started to form, it actually had significantly less functionality than the Haskell implementation. The internal users complained so much about that. And it took just as long to create. What a failure that rewrite was.
In the end, it was the attitude you are espousing that killed the project, not anything technical or hiring-/team-building-wise. It was literally just an opinion not to use Haskell by a guy who couldn't be bothered for the life of him to try to understand it.
Only choose technologies that are popular for production stacks -> more people using those technologies professionally(implying less using others) -> only choose popular technologies -> etc.
From a "making a quality product" standpoint it would make more sense to me to choose the technology intelligently according to the needs of the product. Anything less is just a business mythology about trying to deliver a lower quality product for a lower cost.
The "needs of product" should include "long term maintenance cost".
If software stopped pandering and coddling developers who cannot be bothered to read code we would not need conversations like these. We also wouldn’t need a bunch of superficial nonsense most developers believe they cannot live without. Most companies drastically over spend on finding and retaining developers that aren’t qualified to be there in the first place when really in most cases it’s just about trying to put text on a screen. These companies would save so much money finding people off the street, evaluating them against minimally required intelligence and just training them to read and write code in house.
It's not "super subjective" when something super niche like Haskell[1] is chosen.
There are pragmatic reasons to choose a tech stack, the biggest of which is "can we find people to maintain it?". If you cannot, then it's unmaintainable.
[1] That's the example that was chosen upthread.
It never ceases to amaze me how far you can get with going back to basics of solid software engineering and the manifestations of those basics, mainly:
1. OOP to prove that you have a good grasp of the domain and problem space. Show me you know what's actually happening through code and tests. 2. Build relations - it's far, far, FAR easier to go from BCNF/3NF to a denormalized state than the opposite when you've got lots of data. It's also far easier to perform operations on that normalized state with certainty that your change will fucking work. 3. Focus on APIs first. Whatever the bounded context, focus on the APIs and how they'll be consumed.
He saw DB.Users.Where(a => a.Id == 1) on the screen and launched a tirade of "Are you retarded? You're downloading the whole Users table when you do that!"
It was fun watching our boss explain how LINQ worked and seeing the shame in the engineer's face.
LINQ allows you to use the same syntax for both local arrays and in an ORM, or any data source really, if you implement its IQueryable interface. You implementation can "parse" the AST and generate an SQL query, like a regular ORM.
If a developer working on that sort of task A) matches the coding conventions of the underlying framework and B) employs basic use of docblocks to describe things like function signatures, they're 90% of the way to decent, understandable code that someone else can pick up and work with.
It's amazing, though, how many developers will not do those two things unless you drive home that they're mandatory.
They are pretty objective guidelines that I use to "grade" code in my head and it's pretty rare that anyone who follows them produces code that isn't at least a B, and that other people are able to pick up and extend later on without too much trouble.
And now we have problems A through E.
Personally, through decades of experience, I've learned that when this impulse hits me, I need to consciously remind myself of these truths:
1) The engineer(s) that wrote the offensive code were almost certainly not idiots. The code is probably that way for a reason, even if that reason isn't obvious to me.
2) If I embark on rewriting it "correctly", the odds are very good that I will learn why the code was as it was in the first place, and my rewrite will undoubtedly have my own style, but will not likely avoid whatever issue it was that made me think it should be rewritten.
While I agree with #1, that "offensive" code is offensive for a reason (no time, no experience, no tooling, no hindsight), I don't really agree with point #2. With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing.
IMO: bad code is often due to accidental complexity, often brought in by the programmers themselves. And very rarely due to essential complexity.
> With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing.
You're right. I should have been more expansive. The rewrite may not reproduce the same issue (although the odds are good you'll see what the issue was!), but it will have its own issues, and is also likely to eventually also become "offensive" code that a future dev will have the urge to rewrite.
I use the word "offensive" here in a technical sense, not in a judgmental sense. Great code can become offensive with time as requirements, environments, and development methodologies change.
The main thing is that rewriting code is very expensive in both the monetary and risk sense. In the end, it's a question of cost/benefit. If the benefit of a rewrite is less than the cost, then rewriting is the wrong decision.
> bad code is often due to accidental complexity, often brought in by the programmers themselves.
Yes, I agree. And the majority of it turned out bad because of maintenance. Too much duct tape and bubble gum has accumulated over time.
Bold statement, but closer to accurate than the first impression.
Truth is, the cost of “just rewrite it” is as large as your unit of software architecture. Prefer loosely coupled, cohesive small parts and rewriting to accommodate changed requirements becomes preferable to the alternatives that tack on complexity as landscape evolves.
The world and our model of it both evolve all the time; the current version is not a work of an idiot but a necessary step towards a better solution and a lesson.
Often, you pick "just rewrite it" when the complexity of a module seems to have grown too high and refactoring to reduce complexity or to hit new objectives seems difficult.
The problem is, a lot of that complexity there may be necessary because of subtlety. Or, we may not do all that much better the next time around.
There's a strong bias in software engineering in particular to underestimate inherent difficulties and overestimate our own capabilities. Sometimes a rewrite is a win, but this bias causes us to select rewrites in times when it ends up not being son.
Once bitten, twice shy.
The example that I had to deal with most recently used a "clean architecture" approach in an api. The incoming calls went through three layers of redundant code - of which each layer had its own set of unit tests - before hitting the db and then passing up the response back through the stack.
It deeply annoys me to have to deal with people who have some pattern like this that they read about and, I assume mostly due to its relative obscurity, they feel ... smart? ... when applying it and forcing whomever comes after to deal with it.
To say that I want to viciously rip out the redundant layers is an understatement.
Something something memory allocating llamas cough.
Whether an architecture is objectively excellent doesn't really matter. The question is whether the people who are going to maintain the thing can work well with it. A tribe of OO partisans will produce a very different system than a tribe of FP ones. Each could find their own system highly maintainable but find the others' incomprehensible enough that they'd rather rebuild it than take it over.
What I think really matters is close, respectful collaboration among a group of people in a context with frequent iteration, so that the team can learn to make good choices together. And, over the longer term, enough continuity in that team so that new people can absorb enough context that the culture is transmitted for as long as the code lasts.
A frontend developer that uses lots of bitwise operations and tricky mathematical algorithms to display CRUD is simply a developer who studied those things.
Unfortunately, this guy played management in a way that caused him to keep getting away with the behavior. Awful person to work with!
Time has proven that generally I'm close enough, but I still fear it.
This is my biggest pet peeve of them all. I tell wet-behind-the-ears engineers "always strive to make the life of the next person to touch the code easier, even if only because the 'next person' will probably be you."
I have dealt with opposite - a monolith-based company grew to a point where more complexity was required, but none of the engineers there seemed to have been equipped with an iota of distributed systems knowledge.
The "senior" and "staff" engineers obviously built something, and everyone was still monkeypatching out all the consistency issues 5+ years later, and some of them were still around declaring that there are no issues.
I don't believe 10x engineers actually exist. Maybe 1.5x, 2x, or 3x engineers exist at most. 10x is a huge exaggeration of human capability.
Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month. If such a person exists it will be so rare I estimate that most people haven't ever encountered an actual "10x" engineer. Even a 3x engineer is super rare. I can see something like 2x happening where a project that takes a year is done in 6 months. That is rare but plausible.
You also might get a lead who can ramp up the effectiveness of an entire team by say 3x at most. If the size of the team was N, then it's N*3X. If N is like 4 then it's a 12x increase. This is the closest thing to an actual 10x engineer. But it's not actually a 10x engineer here it's just better management.
This article isn't about engineers that make your team better; it's about engineers that make your team worse.
10x engineers do exist, but they're vanishingly rare. I actually met one once. He eventually burnt out and left the industry permanently.
You've really never met this person? Feels like more or less everyone with real expertise should be able to do this in the right job.
The statement that every engineer can be a 10x engineer is recursively paradoxical. If a 10x engineer existed, in my mind, he would immediately be able to identify this logical error.
I won't waste any more words on someone who willfully misunderstands them.
Nope. I've never met anyone who can complete in a month what it takes an average coder a year to complete.
Neither have you.
i've built in two weeks something that took another guy 5 years to not even quite finish. with better performance, reliability and extensibility across the board.
that's a factor of 130x (or more!). how do you want to divide that up between the two of us? if he's 0.01x, how rare must he be for the "average" to still be sitting at 1x?
Remember, for every Bellard, Carmack or jart: there's at least 100,000 glue engineers who are just trying to cash in some easy VC checks - can't blame them at all.
The true 10x engineer looks at the project, sees the inherent needless complexity, goes back to the sponsor and uses his business knowledge to renegotiate the specs. Leading to a reduced scope with 98% of the business value and 10% of the work.
I think the reason so many people have doubts on the existence of 10x is that they might have never encountered one.
I recall a story someone told me a while ago. Software business that did local CoL/prevailing wages. Hired an intern one summer that was just running around in circles around the other, more senior devs. Useless to say they loved him and the next summer they tried to get him back, even offering a signing bonus for an internship (something they considered unheard of) but he was already at a large search engine company down in the Bay. You can guess the comp was probably already 3x what his previous job was offering. Of course, he wouldn't return.
There's a whole class of engineers were completely invisible to most companies, even if they are in the same "local market" [0][1] (Some use the term "dark matter devs" but I know it has another meaning [2]). These guys tend to fly under the radar quite a bit. If you are in a tier 2 market or company, your chances of attracting one are close to nil. Because they are extremely valuable, they don't interview a lot and tend to hop between companies where they know people (or get fast tracked internally). When hiring is red hot, they might completely disappear from the hiring pool by junior year.
> Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month. If such a person exists it will be so rare I estimate that most people haven't ever encountered an actual "10x" engineer. Even a 3x engineer is super rare. I can see something like 2x happening where a project that takes a year is done in 6 months. That is rare but plausible.
That's thinking in terms of bricklaying. 10x, like Carmack or Woz for example, bring completely new ideas and paradigm shifts. Think of the engineering happening at Xerox PARC for instance.
[0] https://blog.pragmaticengineer.com/software-engineering-sala...
[1] http://danluu.com/bimodal-compensation/
[2] https://www.hanselman.com/blog/dark-matter-developers-the-un...
All of that are arbitrary numbers. 10 is arbitrary and not actually measurable, but your 3, 4 are as well.
But I think you're on the right track with this thinking. "10x engineer" does not make things 10 times as fast as "1x" engineer does, they do qualitatively different things
Take an example of an engineer who sees through the bullshit of a "cloud architect" who specifies a complicated architecture with novel technologies to pad his resume. Cutting down on this can easily save the project / deliver much faster.
This is kind of an interesting view - 10x engineer does not make projects run 10x faster, but they prevent mistakes which would slow down the project by factor of 10.
If mean = 1x (by definition 1x should be the mean) and the std is the maximum possible value (also 1x). Then 10x would be 10 std past the norm.
This makes my numbers not arbitrary. 2x or 3x would only be 2 or 3 std past the norm. Which is reasonable (only if the std = 1x which is likely not the case and is most likely lower).
If a 10xer existed, That's like saying you found a human who runs 10x faster then the mean (10mph) or you found a human 10x taller than the mean (5'10"). 10 is arbitrary but 2 or 3 is less arbitrary. Ever heard of the company 3sigma? The name represents Rarest non arbitrary anomaly from the norm.
It is actually fundamentally illogical to think of human ability in terms of a multiple of the mean because no other measurable human quality follows that kind of distribution. Almost all of these measured things follow the normal distribution.
You are therefore highly highly unlikely to find a 10x engineer or a -10x engineer. This applies even to things like engineering leadership.
When viewed from this lens you can actually see that it's actually very unlikely for even the best leader to improve the productivity of every member of his team by even 2x. So I take that back. Likely what we are seeing is something like a 1.1x.or 1.2x increase and our minds are exaggerating the effect like an optical illusion.
The concept of measuring any human trait along multiples of the mean via 1x or 2x or 3x or 10x is fundamentally unrealistic when you take a data driven viewpoint of normal distributions. Everyone on this thread is erroneously following this model and while my instincts were more tempered, to a certain extent even I'm following this erroneous model as I declared 3x to be within the realm of reality.
We are all going about this all wrong (including me), the data driven conclusion is that at best you can find 2x engineers and they are freaking rare (because the actual std is nowhere near 1x). The maximum likely delta between the best engineer and worst engineer is 4z, where in this case the z represents 1/2x or an engineer half as good as the average.
Likely people are anecdotally seeing this 4z delta and their mind is exaggerating the delta to 10x. From what we know of statistical reality an actual 10x is unlikely to happen at all.
Sorry, but this is a completely arbitrary definition and honestly one I've never seen so far.
So for IQ, or height, no one can have negative or zero height. This limit effectively limits the std. It is not arbitrary. Try it.
For a distribution of integers on a range from 0 to infinite, let's say the mean is 1. The std will also have a maximum value of 1.
If you add extreme data points to change std, you will also change the mean.
This makes sense right? If you add say 9999999 to a distribution of numbers to keep the average the same you have to counterbalance it with a -9999999 or something like that. But however because the domain is limited from 0 to infinite you can't do that. So effectively the maximum value of the std is the mean itself assuming that the system is normally distributed.
For height, sure, but since IQ scores are defined by the standard deviation of 15, a negative score is possible (you’d expect a single-digit number of people in the world population to have such scores.) Not sure if the typical test resolution is sufficient to distinguish that, though.
In other words the statistical model is not an entirely accurate model of the IQ test. Which to me is what IQ is. If negative IQ exists what does it even mean? These numbers have to have some physical actualization. It doesn't make sense for IQ to be some measure of some factor that's impossible to ever actualize.
That's just my interpretation though. Regardless of this though, it is highly highly unlikely for engineering productivity to go that deep into the negative. It's also fundamentally impossible to have infinite productivity too. The real domain is for sure some fixed range of numbers which makes the std for sure limited by the distance of the mean to the first number in the range.
By this logic, A 10x engineer is analogous to someone with 1000 IQ or 58 feet in height. We have intuitions about this that is inline with the statistical outcomes I outlined above... and it makes sense to apply these intuitions to the concept of 10x engineers.
You can now define the std to be whatever you want up to 1x. So I take the most ludicrously large std then interpret what the term 10x means in terms of the maximum std.
10x is in this case, 10 std from the norm IF 1x was the std. So the 10x concept is ludicrously improbable. The real std is likely much lower than 1x this making the existence of a 10x engineer even less likely.
This isn't arbitrary. This is the definitive interpretation using statistics. Science so to speak. If you like to interpret 10x under some crazy uneven scaling or use some other methodology other then science, be my guest. But such actions wouldn't be conducive of a 10xer would it? Which further supports my point.
And it's wrong. Read the title of this discussion again, "How to be a -10x Engineer" and think about what it means for max. std value.
At the end of the day it is 10x what, tasks closed (features, bugs, etc) at same or higher quality? Terrible metric but those people exist.
But you can also be a 50/100x engineer if the metric becomes value rather than tasks closed. E.g. convincing key stakeholders their project is a bad idea can save millions, years and companies.
There's plenty of such moments to make huge differences and they compound.
The most spectacular example of this I've ever seen was a developer writing Java that only ever used single-character identifiers.
As in the following style:
class D {
public A foo(B b, C c ) {
D d = b.x( c );
return new A(d.f(1));
}
}
You might be wondering: what happens when he gets to "z" and runs out of identifiers? No problem! He just kept going thus: aa, ab, ac, ad, etc... I saw code up to "dh" or somesuch.
He had perfect job security... right up until the startup he was working for imploded because nobody could collaborate on that code.
Not all presentations are created equal. Text you throw on a slide in 10 min to guide a 1 hour conversation, versus trying to make everything pixel perfect for 40 hours prepping the deck for the public. Ticket management is critical, but do you really need to spend 4 hours doing it each day?
The company I work for have quite a lot of all hands presentations with content relevant to like ... 5 people. While everyone else nods, sleeps, reads reddit, zooms out daydreaming. We have diagrams that have nothing to do with anything, but make manager feel like she is controlling something.
We do not spend much time on ticked management tho. Which an argument against that idea too - you can in fact have functional ticket management without everyone spending too much time on it. But, I did seen overly complicated systems in the past that required constant fiddling.
For some teams, especially very small ones (and most especially if they're all volunteers), adding significant amounts of bookkeeping to their tasks is likely to be much more trouble than it's worth. (Though, again, even for some solo developers, the bookkeeping can be very valuable—it's all about the specifics of the projects and the ways different people operate.)
For other teams, not having the extra bookkeeping will mean that the people struggle to keep their tasks straight, or get abused by their managers, or have a variety of other problems.
The most important thing is to be reflecting on your and your team's work and processes, and being open to changes that might improve them.
Guh, I remember at a previous job, one of my managers would always dedicate a multiple minutes to pie charts of types of tests done at the end of each sprint - the business stakeholders and the developers at the retrospectives couldn't have cared less that 30% of testing effort was spent on smoke testing compared to 28% last sprint.
Ticket management is stuff that needs doing, obviously.
Diagrams are illustrations; if something is so complicated it can only be understood with a picture, it's too complicated. But a quick diagram on a whiteboard (or with a pencil on the back of a fag packet) might be helpful.
Presentations (with slide-decks) are for managers[0], not engineers. They are a huge drain on time. I got severely dinged by my manager for doing a presentation without a slide-deck; I hadn't prepared one, because I had real work to do. But I think I showed my manager up, because all the other engineers had turned up with slide decks.
A crap slide deck is quick to make, and completely useless. A really good slide deck can take days to make; it's a specialist trade, like making good user documentation. Slides must augment the presentation, not distract from it.
[0] I've been forced into formal management once or twice; my experience was that at least half of management is bragging to other managers about how important your team is, and slide decks are great for that.
Absolutes like this contribute significantly, depending on the perspective they're spoken from, to the anti-intellectualism in our society today, or to a culture of elitism.
For the first, some things are complex, and that complexity is part of the real-life systems and structures they have to interface with or represent. Explaining complex things with a diagram can be an extremely effective method for making what might otherwise require a very high cognitive load much easier to process.
And for the second, if someone needs a diagram to understand something complex, it's not because they're stupid, and insisting that everything worth explaining can—and must—be explained in text only does them a disservice.
It wasn't meant to be an absolute, it is just a rule of thumb, and for me. I expressed it that way for rhetorical purposes.
I don't think retreating to real language is anti-intellectual; but you may be right that it's elitist to mistrust stories told in pictures. Anti-intellectuals mistrust stories told in words.
By contrast, WiX# provides a complete code sample that specifies a complete installer in less than 20 lines, with no diagram necessary: https://github.com/oleg-shilo/wixsharp
I...do not feel that this follows in any way, either as an absolute or as a rule of thumb.
Usage of WiX-sharp (which wraps and hides the mess decribed above) is so simple that a complete sample project is just a few lines of code, as shown in the README. There is no diagram because none is needed.
This is consistent with (but doesn't prove as a general rule) the idea that "if something is so complicated it can only be understood with a picture, it's too complicated"
This could just be bad ticket management with where I work. Or we use tickets in a less standard way. I’m not sure, I work in fpga design so it’s not like a user submitted bug, it’s a request from one of the 1000 review meetings.
I used to despise the incredible amount of time we could spend on a single powerpoint slide sometimes.
Then one day when going over same slide for the 5th time with my boss and mentor, I realized:
* This slide will be seen by a person in power
* they will make a decision based upon that slide
* I would like to spend 3 hours explaining them the intricacies of my project/architecture/problem/whatever
* But they have 10/100/1000 other projects, and they have 20/10/5/1 minute to devote to me before they make a decision
* A slide or set of slides might therefore have an impact across 1/10/100 people over week/month/years due to a decision based on a slide or set of slides
* therefore, it can at times be rationally logical to spend a lot of time word-smithing a slide in order to help the right decision
As programmers, we understand that we might spend 10min/hour/days/weeks on a small but crucial piece of code, because we need the computer to understand it and do the exactly right thing in a complicated scenario; and we do not consider it a waste of time (though our management might! It's a curiously symmetrical situation :-)
Sometimes, slides are exactly that, but for people - distilled information to enable executive stakeholder to do the correct thing.
Same with other items - diagrams? They can be phenomenally useful! A good diagram can spread understanding of goal and ensure we all build the right thing. Bad diagram can set 100 smart people on divergent paths!
Some people do better with documentation or tickets or code or meetings.
The point is that forcing people to do shit they don’t want to do will backfire and make teams unhappy and unproductive.
When you have a small team, you can often organize the work the way people prefer. Then you'll find that people who can be incredibly productive under ideal circumstances are actually quite common.
But as the organization grows, you have to focus more on the process and the structure. Individual productivity doesn't matter if you can't channel that productivity to advance the organization's goals. You rely increasingly on people who can work productively within the system. People who thrive in a wide range of environments, even when they would prefer having things organized in a different way.
This almost always leads to major changes to the whiteboard during the meeting.
Had many times were I couldn’t get company to do this exercise. First time leadership sees UX is on completed project.
Team then spends months rewriting application. Everyone generally pissed.
Yes and no. If I oversimplify one of the important Lean points, you can divide activity into 3 buckets: 1) value-creating, 2) necessary waste, 3) pure waste. It's important here that "value" is always measured from the customer perspective.
For example, imagine a hamburger joint. You have ordered a cheeseburger. The person at the grill cooks a patty for you, puts some cheese on it, and assembles a burger. Then somebody else walks that burger to you. Except they get distracted after they've picked it up, so they end up walking to the back before coming up to give it to you.
Making the burger is value creating. You wouldn't want a raw patty, and you want it put together right. Walking the burger to you is necessary waste, in that moving the burger does not increase its value, but we have to do it to deliver value. The little stroll to the back is unnecessary waste in that you could receive the same value without it. Make sense?
With that framework, let's think about software. Ticket management is not a value-creating activity. If I do an extra hour of ticket management, that does not guarantee increased value. At best, it's necessary waste: I just can't figure out how to get you what you want without N hours of ticket management. But quite often it's unnecessary waste, labor performed for some purpose other than customer value. For example, a lot of planning activity is about making high-status people feel important. Or part of somebody's ongoing battle for increased status. Or the downstream consequence of previous unaddressed failures causing distrust.
So can ticket management be necessary waste? Sure. But it's often pure waste. I've done whole companies with no more ticket management than you get out of a bunch of index cards on the wall. [1] And we got there by relentlessly cutting the waste of heavier processes, something that a lot of companies won't even think about, much less attempt, because there productivity is relatively unimportant.
[1] e.g.: https://williampietri.com/writing/2015/the-big-board/
Another way to look at it: If I put the customer at the bottom of a well and the only way to communicate is by cranking notes up and down in a bucket, does turning the crank constitute a value increase? Mainly I think it's focusing on the wrong thing. Why is the customer in the well? Maybe we should let them out. Maybe if we have a question about how they work or what's good for them, we should visit them and study them as they work and then maybe ask them a question or two. And then, most importantly, ship something and see if it really does make things better.
So no, even in that narrow and unfortunate case, that is not creating value. It is at best necessary waste. Building the thing and giving to them, if it turns out to be valuable, is creating value (probably with some waste mixed in). The fact that communication is through a constrained and stilted channel is just a sign there's pure waste in the necessary waste that we can try to remove.
I've personally only ever seen someone removed from a team for having poor technical skills once and it was under pretty extreme circumstances. While I've seen many good (from a technical perspective) developers removed because they thought they were somehow above doing the everyday "busy work" like ticket management.
Unless you work alone, then refusing to do non-technical work is just saying you're going to let the rest of the team do it. You're much more likely to be removed or have your contract ended if the team doesn't want to work with you.
I just think that there’s an incredible set of decreasing returns after about 30 minutes into building any diagram or presentation, for most people and most use cases.
That’s why quick whiteboard or lucidchart or Miro sketches are so powerful - and are designed to communicate in the moment! - and most PowerPoints, swimlane diagrams etc which have tens or hundreds of hours of work are like polished turds.
Very few diagrams or presentations show history and almost none are ever updated to show the status of things today. Which means that they just cause confusion. Generally, someone starts again and creates something with new blind spots and which takes about as much time again to create, and is out of date before others see it.
Drawing and presenting is mostly interesting if the people who are present for the drawing or description process can go forth and explain, draw or present it in their own words or images, and therefore communication has been achieved; this seems to be very uncommon in most drawing and presentation-heavy environments I’ve been in though.
I say this because there always seems to be those who don't need this. And it's the ones who need this who never seem to produce as much or are able to solve the problems on their own.
So I ask. If you could hire people who need this "communication" or hire people who don't need the "communication" and they both can get the job done, why would you hire those that require time consuming processes.
Good teams don't need Jira, good teams don't need power points, good teams don't need all the hand holding. These are tools to include those who can't and often bring minimal usefulness to the table.
Poor communication is code for "I have no clue what I am doing and am going to blame others for why I am not useful, but I don't want to admit to others I have no clue what I am doing.". Next time you find your self thinking somebody is poorly communicating, try this in stead. Say "Hey, I don't know what I am doing, I am lost, where can I start? More often than not this "poor communicator" is going to be able to direct you to a task that will not only make you useful, but also not require much more than 5 minutes of exchange and as a result you will probably learn something that will make you more useful in the long run.
> in my experience it has been the sub-par employees who are the ones that don't do this.
To directly call this out, the sub-par are often the ones doing all this stuff, because they simply can't do the actual work. Sub-par is probably not fair, as a good manager will build a team with a few of these folks to tend the toil. So they are useful in a way.
Also you all can think back on the time that you hired somebody and they knew more than just about everybody about how the product works and should work within just a few weeks. This person clearly did not need the documentation, they simply read the code -- the code is the documentation -- and the quicker folks stop thinking like tis anything else other than a big manual the faster they will be able to learn new code bases and become useful. The constant translation between weird human social ideas of what is good communication and a solid structured communication such as code its an incredible waste of time.
Just remember, your job is to write code to tell a computer what to do, and if you can't also read that code to figure out what the program should do, you might be computer illiterate which makes you less valuable than somebody who can both write and read code in the same manner as the systems that will consume it.
If you have ever had somebody tell you "it's like you compile the code in your head" you will know what I am talking about.
How do you even know what to work on without communication? Most real systems are used by real people who aren't the developers themselves. Product owners, business development, customer support, and a myriad of other people all usually sit outwith the developer teams. Are you talking directly to customers for feedback on feature development?
As if turning a measurement into a target could make it cease to become a good measurement!
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.
I don't want to empower jerks.
Anything particular I should change? Or is the structure of the essay too cynical overall?
We are HN. We are legion. Expect us.
When I got on the site, btw, I immediately saw your choice of font and I didn’t actually read your essay.
PS: This is satire (https://en.wikipedia.org/wiki/Poe%27s_law)
Granted, pointing out problems is generally much easier than solving them, and correspondingly less valuable. As I like to say, stand up, spin around, and point at something randomly. You're pointing at a problem of some sort.
But that still does not incur a responsibility to someone pointing out a problem to also solve it. It's a popular idea for some reason but not one that can stand up to scrutiny of any kind.
The problem with the article is even though it’s right it makes no attempt to explain why, and blames bad people for the problems instead of understanding why they might be acting like they are.
No, it isn't their job to understand the problem before pointing it out either. That also does not stand up to scrutiny in the slightest.
If I call my township to report a big pothole, I am not required to submit an explanation of how the pothole came to be. This is a ludicrous standard only deployed when situationally convenient for someone, not an actual principle.
Again, the value of a problem report without an understanding may be less than one that has it, but there is no obligation to have an understanding or present one in order to talk about a problem at all.
Frankly, this sounds exactly like toxic management where people are not allowed to raise issues which then blames everybody but themselves for consequential infectivity.
> If I point to a light switch and call out it’s a problem that does you no good unless I tell you why, and why it’s like that in the first place.
I I point to a light switch and say that it does not work, I do not need to be able to fix it by myself. For that matter, it is good example, because we are not even allowed to fix electric devices by ourself (workplace safety).
I don’t think you’re saying that you couldn’t explain why the light not working is a problem. No one said you have to know how to fix it.
> If I called out every problem with all the code I work with no one would ever get anything done, because everything is tradeoffs.
Obvious difference is that article did not complained about trivial issues. It complained about very real issues that waste massive amount of time.
> I don’t think you’re saying that you couldn’t explain why the light not working is a problem.
Adding "I do not see without light" is completely unnecessary when complaining about broken switch. There is zero need for it. Similarly, it is no mystery why issues in article are problems.
If you are unclear about why any of listed issues is a problem or disagree, you could have made that claim. But, neither parent nor you claimed not understanding that. All you want is to prevent people from talking about these issues.
Other teams like marketing need to make schedules because they spend huge amounts of money doing things to make your product successful, that have nothing to do with code. For example, launch events, advertising, conferences, executive briefings for key customers, etc. Planning, dates, progress reports, etc are all needed because unless you are a lone open source developer, you have to work with others.
Users will use your software in unexpected ways. Hackers will try to break it. And users will expect it to work flawlessly when they need to use it to generate their report for their VP meeting in 5 minutes. Testing is critical to ensuring that your software doesn’t suck for your users and make them hate you.
The business you work for probably doesn’t exist with the mission to leave you alone and let you code. They want to solve a customer problem by creating, marketing, selling and/or supporting a software product. Your management wants to know that all the money they are spending on your salaries is getting them a positive ROI. Letting them know what you’re doing and providing them with content about capabilities and features that can be used in marketing, makes them want to keep paying you. Missing deadlines, failing to deliver non-code deliverables, failing to provide status, and being jerks in general make management want to cut your project (and maybe your job) and do something else with cooperative people.
Yes, there are pathological extremes to all of these things and to the points you raised in your post, but I see too many developers who think that developing software is just about coding and that everything else is extraneous. In reality, the vast majority of your time is probably best spent NOT coding.
[ed] spelling, paragraph break
This is all true for the somewhat narrow field of commercial software development for the consumer end-user where profit margins determine success or failure in terms of paying off the capital investors, but many organized engineering efforts have other goals, e.g. replacing some organization's decrepit internal data storage, archiving and retrieval system where robustness matters more than anything else, or designing a research program aimed at solving a complex technological problem, writing software that controls an electrical grid, and so on. Applying the maximize-short-term-profit mentality to such problems generally doesn't end well.
If you're offended, this article is probably for you.
- if you can't define "jerk" well, you're playing into office politics. Who decides who the jerk is?
- there's a typo: "A blog post by the studies authors" should be "A blog post by the study's authors"
- the "studies" linked to seem fairly dubious. Most people who are rude are not so because their boss is. Only 25% said they were. Also, it's qualitative survey data, which it's rarely a good idea to draw anything but first order conclusions from (e.g. yes Donald Trump won the 2016 election, so we can conclude that he got the most votes, but we can't infer from that that voters like candidates with orange skin). And as self-reported data, it's hard to base much on it at all.
- the implication is that removing all this would be the best thing, and that's probably true: having some wonderfully polite geniuses is no doubt the best option. However that doesn't mean we should necessarily prioritise politeness over raw ability, as at least for some tasks, a solitary person who's very smart can do things that even teams of others can do.
You want to sound like an Office Space character. But in Office Space, there is no mission, there is no good engineering to do. So all the douche-y people who get in the way of work are more pityful than enemies.
But here, you believe in good engineering yourself, and the -10x engineer you encounter get under your skin. So you're venting online about why you hate their guts (in a funny way, for sure, but still the aggressivity transpires)
It's understandable. I met many bad engineers. They're a nightmare to work with. And yes, many will have a net negative impact on overall productivity. Still, coining the term -10x engineer and making an aggressive piece about all the ways they can screw your work life is not exactly healthy.
Yes, I think your post is going to be empowering jerks. What did you think? That this was just a "funny, haha" post? There are many people who are angered by bad engineers in their daily lives. This is just adding fuel to their anger. This is the Jerk effect taking place. This article reads like a jerk venting, and that language will spread to frustrated people. You can already see it in the comments here.
Yet, I also met an awful lot of terrific engineers who were brutally aggressive towards anything they felt was stupid. And in my opinion, those people cause at least just as many problems as people who perform really poorly.
I think the tone of the article (cynical, exagerating bad traits, etc.) promotes that kind of toxic culture, while not bringing much to the table in terms of fighting mediocrity. That is all.
But assuming your goal is to make a positive impact in the industry, managers need to be able to read this and get actionable takeaways.
You’ve got my attention as an engineer, but a follow up post for each of these examples would be the place to close the deal. They of course would have to be written with a different (and dare I say more constructive) slant. It needs to be something someone can take to a manager and get a chance of some good conversations. It can still be persuasive, but in order to be actionable I would expect specific examples, clear definitions of the issue, and recommendations that tend to be familiar or standard.
I would do plenty of research too. Because for one thing you need to ensure you are giving correct advice. But it will provide a massive boost to your credibility to include that research in the posts. It will also save your reader the trouble of doing independent research (which they likely would not have done in the first place but still require it for actionable change, or the idea gets shelved). -10x engineers can leave managers no time to do that kind of diligence, but the managers still know better than to blindly trust what someone says on the Internet. Back up your arguments with evidence where possible.
I know it’s a tall order but if you have the time to put that much quality into a series from this, it could be great. I only say this because from what I can see, you do know what you are talking about, and clearly have passion about this.
I look forward to reading anything you do come up with, whatever the approach :)
No matter what is written, someone will find something wrong with it. Expect those people to show up and sometimes be very loud.
I appreciate your efforts to receive feedback. In this case, you'll find the majority of people aren't complaining, just a few are. So be happy that you wrote something that so many engage with!
The only thing worse than writing something that people are critical of is writing something that's completely ignored.
I can't recall the quote verbatim, but somewhere in "The Glass Bead Game" a great teacher says that it's difficult to work with intelligence--you have to be lucky to identify it and then the best you can do is get out of its way. Stupidity, on the other hand is easy to identify and easy to correct on a case-by-case basis.
There's value in inverting a problem like you've done in the article. It might not be symmetrical. Things that might not have been obvious in the original become obvious in the inversion.
Also, the thing about wasting 10 weeks of wages on cloud computing was confusing because it mentioned buying exotic hardware and in my experience the options via cloud computing are never exotic, and never have a decent amount of RAM.
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...
The author probably thinks these issues are caused by bad people instead of bad processes, which is why he doesn’t suggest realistic fixes.
Author here.
This is an excellent way to phrase a subtle point that I couldn't figure out how to fit in the piece.
I think that -10x engineering is not someone you are, but something you do. And even more commonly, it's something that organizations do for periods of time.
-10x developers can get the just by promising things people depend on but never deliver.
I find that the article hides a deep aggressivity towards overall mediocrity behind a thin veil of office-space-like humour. And I think that aggressivity is contagious and so not a good thing to spread.
The post came off to me as frustrated not aggressive. I think you are overreaching here, and this can create very toxic environments as well. Disagreements, frustrations, and stress are just part of being a human. They're part of getting work done. Being toxically negative or positive is not a good thing both in the workplace and out of it, and this post was not aggressive, just being frustrated. Frustration can be good! It signals things that we need to talk about, so we can focus more on them. Hiding them only makes the problem worse.
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.
It’s an unfortunate reality that engineers (not their managers) are responsible for knowing how to handle themselves in the worst of situations so they don’t become the scapegoat at the cost of their health and security. Trust me, I’ve been through this situation and have been burned out by the [apparent] low standards and [apparent] double standards.
The prodigal charismatic leader can save the day but become a crutch too much relied on. And I get it, with all the shit we deal with in life, things ought to work out that way. But eventually that leader won’t be there for you (or even in the picture at all) and you’ll be in big trouble, especially if you spent many years relying on them for help.
Working remote for a high pressure early stage startup is a good recipe for this kind disaster if you aren’t great at managing stress or conflicts at work.
I thought I could count on the charismatic leader to save my bacon by only calling on them for help when when things are visibly on fire and my own minor charisma hasn't been enough. In the end the leader didn't show up and now I've got a HR complaint against me for following up consistently when the fire didn't get put out. The whole thing has been fairly stressful because I'm struggling to understand the particular social dynamics, my best guess is it's just power protecting power, but I am naive/delusional enough to want to believe there is more to it. Now I'm taking a month off from work to try and unwind a bit.
All of that was just a long way of saying that you never know when you'll need to call on your stress/conflict managing skills, so best to keep them sharp at all times. I thought my skills were already good, but that was quickly revealed as false when challenged by tougher opponents :).
Step 13: have a blogpost about how inclusive and equitable your company is.
step 17 Recognize that questioning the status quo is a critical part of progress and growth, and that "toxic negativity" is often a label applied to dissenting voices to silence them.
step 18 Acknowledge that engineering, like any other field, can benefit from improvements in productivity and efficiency.
step 19 However, also acknowledge that a singular focus on productivity can lead to shortcuts, neglect of quality, and burnout among engineers.
step 20 Question any proposal that seeks to boost productivity without considering its potential drawbacks or unintended consequences.
step 21 Encourage open and honest discussions about the tradeoffs involved in increasing productivity, and welcome feedback and criticism.
step 22 Remember that criticism is not the same as negativity, and that constructive criticism can help identify problems and find solutions.
step 23 Avoid dismissing criticism as "toxic negativity" or labeling critics as "problematic" without engaging with their ideas.
step 24 Recognize that diverse perspectives and voices are essential to a healthy engineering culture, and that dissenting opinions can lead to innovation and progress.
step 25 Cultivate a culture of respect and openness, where all voices are heard and valued, and where criticism is welcomed as an opportunity to improve.
step 26 Challenge assumptions about what constitutes "productivity" and explore alternative approaches that prioritize quality, sustainability, and employee well-being.
step 27 Remember that engineering is a human endeavor, and that the well-being of engineers and the communities they serve should be a top priority.
step 28 Take a shortcut and jump directly to step 42 for your surprise.
step 29 Recognize that productivity gains should not come at the expense of ethical considerations or compromises in safety standards.
step 30 Encourage ongoing learning and professional development among engineers, so that they can remain up-to-date with the latest technologies and practices.
step 31 Ensure that engineers have access to the resources and tools they need to be productive, without sacrificing their mental or physical health.
step 32 Celebrate successes and learn from failures, without casting blame or assigning fault.
step 33 Remember that productivity is just one aspect of a successful engineering organization, and that teamwork, collaboration, and communication are equally important.
step 34 Foster a culture of trust, where engineers feel empowered to speak up and share their concerns without fear of retribution.
step 35 Recognize that engineering productivity can be influenced by external factors, such as economic conditions or resource constraints, and that some challenges may be beyond an individual's control.
step 36 Encourage interdisciplinary collaboration and cross-functional teams, to break down silos and encourage a diversity of ideas and approaches.
step 37 Always be open to feedback and criticism, and recognize that even the most successful organizations can benefit from continuous improvement.
step 38 Emphasize the importance of work-life balance, and support policies that allow engineers to take breaks, recharge, and avoid burnout.
step 39 Encourage knowledge sharing and collaboration across teams and departments, to foster a culture of continuous learning and improvement.
step 40 Seek to understand the root causes of any resistance to productivity improvement, and engage in constructive dialogue to address those concerns.
step 41 Consider the long-term consequences of any productivity-enhancing measures, and make decisions that promote sustainable growth and development.
step 42 Realize that in this message only steps 16, 28 and this one where not generated by ChatGPT.
I was wondering why all these steps were generally GOOD things to do instead of the BAD things that all the previous steps were (1-15). And I was wondering why they all sounded the same.
I've seen the behavior OP calls out more commonly associated with toxic behavior than the reverse.
The suspect the people who manufacture make work for others to justify their existence are often aware of their redundancy on a deep level. That frequently manifests in the form of toxicity when their make work is challenged. You're challenging their meal ticket and house-of-cards identity all at once.
Fortunately they're relatively rare in my experience. I've only worked with one or two.
EDIT: ...as proven by the rain of downvotes...
Yeah, or as it's scientifically called: "realism"
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.
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...
The study you linked assumes the actors are not stupid.
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.
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.
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.
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.
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.
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".
The desire to add $TECHNOLOGY to run a relatively small site even though it will likely never scale beyond what a single postgres instance running on a mac mini can handle.
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.
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.
Agreed, most of the times it does not even make any sense in the grand scheme of things to go on those kind of crusades. Also, don't be the saviour no one is asking for.
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.
"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.
A lot of legacy software is like this. I wonder how many billions it costs the economy per year.
No, it must pass a preview before being merged into staging
https://archive.org/details/SimpleSabotageFieldManual/page/n...
Pages 28-32 are the most referenced but the rest is interesting too.
The business was relatively 'boring' - core product would move slowly. But management kept hiring bad people and losing talent. At some point the ship started to slow down.
Those smart people quit to competitors and even some launched their own company that is growing fast.
No bad employee was ever fired, their tasks were just allocated to the few good ones. Who started to quit en masse.
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.
It is that moment of realization that you're entirely responsible for the fate of the company, and you either think "I better tread carefully" or "This should be rewritten in Rust."
The third-party asyncio alternative Trio, on the other hand, has recently added "guest mode" [1] to plug in external event loops, so maybe that will become the one true way to do async.
[1] https://trio.readthedocs.io/en/stable/reference-lowlevel.htm...
By making things in your own language, you stay ahead of the learning curve while others stay perplexed.
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.
> "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.
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.
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...
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.
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.
So you either worked on the biggest codebases in the world
Or youre doing CPP :)
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
I agree that arguments for and against are tiring, so let's talk about the article instead!
I've definitely seen engineers who have been net negative in productivity. They've distracted me from my work, introduced bugs that have had severe effects on the production environment, and have produced code that had to be thrown away and completely rewritten.
Luckily, the items in the article aren't commonly seen all in one person, but they are great ways to lose productivity and negatively affect others in the company.
Encourage doubt and confusion that one person can make a 10x difference. Jim Keller is a lizard. Great engineers are a myth. Play up to the worst cynical beliefs of management: all engineers are just wasteful bums on seats, then prove them right.
I am slow as a snail
- 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.
Name a class "Entity" and make everything else derive from it. Write code that can't be deleted, ever.
Though that might actually end up costing more that 400 hours of wasted time.
We had two things:
a. Poor systems and poor communication permeated the IT department
b. IT was viewed as a cost center so no amount of heroic intervention was ever rewarded proportionately to business impact. It was Sisyphean.
If you are in a situation like this, please run away. You can't win - either the free market will destroy your employer, or your employer will destroy you.
Serious question: isn't it always?
Basically, if IT + Product Development are in the same financial "bucket", IT can be viewed as directly supporting product development.
In short, software development should most of the time be treated as a group activity and you should consider how the output of your own work affects those around you. While you might not feel like documenting your decisions is a wise use of time, it could help others down the line. The same goes for choosing the simplest solution that works well vs going out and writing lots of "clever" code. Things like the ways how we communicate, how much nitpicking vs accepting "good enough" solutions all compount and have a pretty great effect on the output of others.
So true. But only 20 seconds? The project im working on takes 20 MINUTES to compile for any code change. I constantly forget about it while trying to get something else done in the mean time. It frequently takes whole days to track down and verify simple issues.
LOL, I thought I was cynical
Reminds me of the CIA sabotage field manual: https://www.hsdl.org/c/abstract/?docid=750070
On another note, many of the items there are "create pointless X". It's actually a thin line between "important X" and "pointless X" and many people will disagree where it actually lies (as evidenced in the comments here).
This one hurt personally. I didn't write it, we maintain it, but we have no time to go back and write real tests.
I transitioned from startups (for 10 years) to a large company (for 5 years). Part of that move was adjusting from a culture of no lengthy documents to a culture full of lengthy documents, and I would never want to go back. Having explicit documentation in writing, where folks can debate the merit of ideas is so so much better than having it living in a few people's heads, unable to be critiqued.
Edit: add a word.
Mostly spot on but I am not sure of this one - well written notes / emails about technical issues and some of the trade offs or desired outcomes are really useful - they actually help "align" people. Think more "Linus rant" than "CEO powerpoint" but the idea is there
Anyways ive seen so many "programmers" that sit silently in meetings and also just do not produce good code. Usually they produce bad code that I have to revert.
I replaced it with an index, it was a pretty straightforward index as well, imagine the pain if the original design was somehow implemented.
Important to note that there are also 10x environments that make everyone in them 10x as effective.
* Have an agenda and circulate it along with the invite. Let people know what you want to discuss so they can prepare. * Know what outcome you want from a meeting and let people know in the invite. Again, it lets them come prepared and even better, make pre-meeting suggestions. * Think about who needs to be involved. Do you really need everyone, or just one or two people. Again, agenda lets folks know if they can contribute or if someone else needs to be pulled in.
It's not that meetings are bad, but bad meetings waste lots of people's time. Good meetings save time.
Oh, and write down meeting minutes and publish results. The person you're recording this for is usually yourself. :>
Instead of having 10x engineers, make the team 10x. Shape Up (https://basecamp.com/shapeup/0.3-chapter-01#making-teams-res...) by Basecamp is the best resource I've seen on that topic.
Sure, the end result is a less perfect codebase. But considering code isn't the end goal - a working product with happy users is the end goal - imperfect code can be the right way to achieve that.
And besides, all code that is still in production in 5 years is probably due a rewrite anyway - now that the company has pivoted a few times, the product has evolved, and the use cases aren't what they originally were. The computing landscape will also have evolved (eg. new language versions, new library versions, new hardware with different strengths and weaknesses, etc)
Will braces around if statements matter when QA comes back with a regression 4 weeks from now or when Product has a new feature request? Probably not, so a "LGTM with a nit" is warranted.
Adding a json request body to this GET request? Yeah, I'll have to remember that little bit of quirkiness, and quite frankly if the team member is adding bodies to GETs, I can't rely on them to remember that quirk or solve anything after that. So while that is technically a "style choice" since it does work, that's a blocked PR until Requested Changes are made.
However, exposure to cynicism and witch-hunting, such as labeling someone a "-10x engineer," can lead some people to become disillusioned and potentially adopt harmful behaviors intentionally. This can create a vicious cycle indeed.
Obviously, I'm the odd man out for saying a project can be done by 1-2 engs in a month. This said project is being currently done by 10 engs who are all writing boilerplate code since two months.
The management is not taking responsibility and I can't believe everything that is said in the post is fairly accurate.
Accidents happen, the fault lies on whoever did not backup the data.
The person who wiped out the data should be thanked for uncovering the serious problem.
But
> Add dependencies that demand 400 hours of maintenance.
These suggestions conflict with each other - if you're one of these "don't ever write code if somebody wrote something somewhat similar" types, you're also the one adding terabytes of dependencies that have varying levels of documentation and stop being supported at arbitrary points in the future.
And is this a linear function ?
X does 10 things - what things ? - 2X does 20 thing ? --> linear ..
There is no 10X engineer, there is authentic, lover engineer for me .. Lets skip comparing us each other, in right place, right will, and a little love every dev is 10X.
Rest, never ending run, never ending desire, never ending darkness.
However if there are two of them, their product is negative.
Or perhaps I am perceiving a dysfunctional pattern that really isn’t there.
Yet, even if they are imaginary, their impact is real.
This is the business model of roughly 7 out of 10 startups.
Honestly, I've just been yearning to meet new people who love making things.
It's super fun chatting with strangers on the phone!
EDIT:
Actually, if y'all have extra money lying around, consider donating to my AIDS/Lifecycle campaign :)
Improve living conditions for people with HIV/AIDS
1. (Sum of total output) / (Count of engineers)
2. CS grad with a "B" GPA, 3 years experience, 1 year on the team
3. 50th percentile of all engineers
4. <- Me (or whoever the reader is)
I answer almost all questions posed to me with a simple have you read this (confluence link )
That reminds me I have one of these in the wild. Hope to resolve it one day...
Oh how I don't miss working in an office. Avoiding work, overthinking things, and overbuilding.
TLDR: customers don't pay for beautiful, elegant code dealing with the happy path only.
What the reasonable alternative though? What's the happy medium?
...and this is the natural result of the 'no comments allowed in the code' nazi's that seem to permeate lots of organizations. For the life of me I could never understand that particular bandwagon.
I for one love it when I go back into my code after a few years and a few well placed comments remind me why I did what I did last time I worked on it.
Talk about a bone-headed outcome of claiming 'we don't allow comments in our code' mentality.
/* Using Duff's device see <reference> for speed and code size */
The poor developer assigned to replace it with "better code" had an impossible task because they couldn't find anything to replace it that wasn't either much slower or much bigger.
* Useless, like "locks the mutex" before a mutex.lock().
* Contrary to the code, like "This parameter contains the proc name without the instance" and then the parameter does contain the instance.
* Dubious, like it's not obvious what the comment means nor if what you are doing follows the comment or not.
Worst thing is when the code and the comment contradict and there's no good reason to trust one over the other in what the code should do (never go to sea with two chronometers).
I suppose it depends on the codebase you are working on. If it's your own code the likelihood of you agreeing with the comment increases, ofc.
claim high-value projects/tasks, but don't finish them. when another team starts working on the same problem, schedule a meeting over their head and tell the other team's director level that you're already working on it and it's a waste of resources for multiple teams to work on this simultaneously.
Let’s let AI do all the busy work for us.
I personally just want to think deeply, share ideas and connect with people.
I don’t want to be forced to do any meetings, presentations, tickets, code, documents…
I do want to produce some of those things, as long as I feel like they help me in what I want to do.
I want AI to do all the shit I don’t want to do.
I still want to work, interact with people, feel needed and feel connected. Just not forced to waste my time.
https://twitter.com/larsbrinkhoff/status/1642569175657771009