Hacker News Reader

Comment by heisenbit | Hacker News Reader

> But if I had any kind of point, it would probably be that spending the time to do things like write tools and explore the debugging space is pretty much always worth it.

> Strangely, I've found that there is a not-insignificant number of people are against this - especially in a professional environment. I think this has something to do with the JIRA-fication of development process, where all work is divided and sub-divided, and anything that does not directly check a box and produce a deliverable is wasted effort. It's disheartening that there is a whole group of people - developers and managers alike - who do not understand or see the value in exploration as part of the process.

So true, being able to create your own small tools is a superpower which is often at the heart of 10x programmers. It is sadly an art often practiced in the shadow.

View on HN

I've run into this as well. There's a cog in the wheel developer and ... they have their place, and in many orgs they're the only thing that works.

But if you're not that person (and I like to think I'm not) and you are curious and stop to think about second order effects, future features that are a little obvious, and so on ... it's really painful working with those developers who do not.

I worked with one recently, not a bad person at all, but now I'm cleaning up his project that 100% did exactly what the tickets told him to do. And the project that he worked on that was designed to replace a piece of software that had issues ... has every single issue the old one had for all the same reasons (someone coded it in the easiest possible way + only what the ticket told them to).

So frustrating.

I will say this though, I find the use of the term "10x developer" a sort of buzzword smell for the kind of reckless developer with no oversight who "gets the job done" at great cost ... because they can do what they want and then everything is siloed and potentially a disaster when anyone has to touch it or they bolt when it becomes clear their tower of cards is ready to come down.

Not to say I disagree with your statement generally, just that term tends to make me worry.

I'd say that there are two kinds of 10x devs, as per who is doing the determination of '10x':

1. From the perspective of the money folks (managers & up): they get their jobs done very quickly, thus spending minimal time, meaning minimal money.

2. From the perspective of excellent systems design folks: they design an excellent system that addresses subtle problems and foresees and addresses system problems that will occur down the road.

Type #2 folks tend to not add to the org's technical debt; Type #1 folks don't GAF about such considerations -- they meet their quotas, get their perf reviews, and are on their way to their next promotion/position/project.

I'd say there is excellence for excellence's sake, and then there's money-making excellence. Sure, orgs need to make money (or at least break even) to survive, but there's a lot of overlap where being too much one way or the other will be an impediment to long-term viability.

And then at Boeing with #1 the doors fall off…

> the doors fall off

"That’s not very typical, I’d like to make that point."

https://m.youtube.com/watch?v=8-QNAwUdHUQ

Not sure what that has to to with writing software. If I take your perfectly written code and run it on bad hardware that corrups memory and a CPU that does math wrong (aka don't tighten the bolts down all the way), it's going to cause problems, regardless of if it was a #1 or #2 type engineer that designed the system.

Be careful about generalizing about Boeing here; it's not really a good example. The door plug incident was entirely caused by managers, not bad engineering.

In this case, the managers knew that if they went back and removed the door plug then it would have to be inspected again. That would cost time, and the plane was already behind schedule. Their bonuses were in the line, so they got together to find a solution. The solution that they found was to skirt the inspection rules using semantics. They decided to have their employees loosen the bolts, shift the door plug a little, do the required work, and then put everything back. This allowed them to claim with a straight face that they hadn't ”removed” the door plug, and therefore it didn't need to be inspected.

It was bad engineering full stop.

Yes the root cause might stem from management but good engineering would not have the doors flying off... thus bad engineering. Regardless of everything else, engineers are responsible for their designs at the end of the day. (Yes when management only approves cheap unsafe designs)

Otherwise you are "just following orders" which is not a viable leg to stand on.

I disagree. First, remember that we’re not talking about doors here, but walls. Specifically, a door plug which is a type of wall segment that can be put into the space where room was left in the airframe for an optional door. If you cannot get that detail correct, maybe your opinion doesn’t count for much.

Second, the steps for assembly of an airplane are all very important. If any of them are skipped or left out somehow, the plane will break! You can’t engineer your way out of this problem either: the more ways you add of attaching that door plug to the airframe, the more possibilities there are for mistakes. That’s why the assembly process requires one team to install the plug and another team to verify that installation was completed correctly and according to the specifications.

Any time you have managers using semantics to weasel their way out of the inspections that verify that the plane was assembled correctly, that’s the mistake. Full stop. Fire those idiots.

You absolutely can engineer your way out of those problems. There is always a simpler, easier way to put things together.

https://x.com/SpaceX/status/1819772716339339664

I think what happened is, Boeing codified all these labor-intensive manual processes back when they were riding high. The planes were selling well, they were state of the art. Now, 30 years later, it takes the same amount of effort to put everything together without mistakes, but the relative value of the finished product is less.

I'm kind of in that boat as a "reckless developer". I come in and write little tools to help people workflows, automate something that was a manual process or a shell script to get the job done instead of doing it by hand. Some of these scripts can grow into big projects over time depending on if I'm the end user or someone else. No one asks me to make these things, I just see a issue to resolve and I resolve it. I like to call my self a hacker really since it makes sense in the old terminology of what I do with the many hats that i wear.

> if you're not that person and you are curious and stop to think about second order effects, future features that are a little obvious, and so on ... it's really painful working with those developers who do not.

Not only that, but it's also really painful working in a system which doesn't really value your artwork because you're not on the product team, and shouldn't be making product decisions.

I understand your concerns around 10x Dev. May I suggest a different term more specific to this discussion? "Tool builder", as in, one who builds tools for them self, and possibly shares with others. I have worked with programmers that were not outstanding in terms of pure computer science, but could build a tool or two to get leverage, especially around system transparency/debugging, etc.

> It's disheartening that there is a whole group of people - developers and managers alike - who do not understand or see the value in exploration as part of the process.

To steelman, because, as Frank is sending ethernet packets, we're stuck picking up the slack, doing things that are part of the job description, that are needed by the org as a whole. Why doesn't he just innovate in the actual problem we're working on, since there's a near infinity backlog?

I think, ideally, everyone is given exploration time, but that requires a manager that can strictly defend it, even when upper management is made aware of it and inevitably says "we need <project> done sooner". It's also a problem when other managers become aware of it with "You're allowing that team to hire more to compensate for the "lost time"? We need those people!". It really needs to be an org level thing, which even Google gave up on [1].

"Unethical" solution: Pad your development time to include some of it.

[1] https://hrzone.com/why-did-google-abandon-20-time-for-innova...

> we're stuck picking up the slack

You may be on a team that has decided "developer burnout" is just an inevitable and acceptable cost of business.

> since there's a near infinity backlog?

Which is a problem in and of itself. In any case I'm only going to be able to give you like 4, real, solid hours of work a day on that log. The other 4 will be team coordination, managing that log, and stress management maybe while I hate eat my lunch.

> everyone is given exploration time

Call it "skill investment time." We're in a fast moving industry and keeping heads down for too long is destructive personally and organizationally. It's also the pathway to getting more than the basic level of engagement above.

> You may be on a team that has decided "developer burnout"

No. Burnout is a work life balance thing more than a "doing work at work that is related to the business" thing. Fun can be had outside of work hours, just as everyone else who is employed handles it. You can give people meaningful work they're interested in and still keep it related to the actual business.

> Which is a problem in and of itself.

Absolutely not. If you don't have a near infinity list, then that means you don't have a roadmap. Why aren't you thinking about the future?

> Call it "skill investment time."

Yes, and this can always be done in the context of the work. If it's not related to the work, or the business, then it's not an investment for the people paying you.

> Burnout is a work life balance thing

It's more than that. Perhaps you haven't been in a position to accept a lot of resignations in your career. Burnout is most definitely implicated by the work place itself, specific work assignments, and general office culture.

> don't have a near infinity list, then that means you don't have a roadmap

Are you talking only about startups? That would make sense. In the more general case I doubt your assertion here. Does this fragment truly sound rational to you on a second reading?

> and this can always be done in the context of the work.

The very article this thread is attached to clearly shows how false this is.

10x developers (sweeping generalization here) are often not the ones that are beholden to a manager / product owner telling them what has the highest priority though. Whether that's because they won't be told what to do, are the manager themselves, or have no manager at all is not known to me.

That said, writing your own tools if applicable is useful, however I'd argue that a productive developer writes the least code and instead uses what's off the shelf. To use this article as an example, nobody should be writing their own TCP stack, there are perfectly fine existing implementations.

That said that said, writing your own stuff is probably the best way to get a deep understanding, and a deep understanding of things is a constituent part of the mythical 10x developer. I just wouldn't expect any employer to pay you for it.

The reason a “10x developer” can work on whatever they want is because it only takes 10% of their work hours to complete their job requirements- they are then free to experiment and play with a lot of their time.

I second this notion. In my experience, the most efficient / effective developers get to work on all sorts of interesting problems because they can finish their "regular" work so quickly.

A good manager recognizes that a good 10x developer needs minimal management. Not that they don't need managing, but that too much management throws a wrench in the mental gears and drags them down, burns them out, and forces them to quit. All they need is a light hand on the steering wheel to keep them pointed at the right problems.

But sibling comment is also right. The 10x developer has more "free" time outside of their Jira tickets. Some choose to focus on the next business problem, others drift and experiment.

Either way the business problem gets solved and you retain a very skilled employee. Their explorations may turn up something valuable, or just add to their own personal dragon hoard of skills, when then usually still benefits you in the end

Yep. I've had both polar reactions:

"Wow that's really helpful. Your tool confirmed our model."

And

"Did you ask the PM first? You have to be careful with rabbit holes."

I usually just do it if it'll be under a day's worth of work. It's never gone wrong and never gone to waste. At worst I and up copy/pasting the code into something else later

Me too. #2: Run away...

Recently at work I developed a small suite tools (in a mixture of python and shell, running in WSL) that left my boss impressed when he saw me debugging a customers system (IOT).

Then he started asking me to make them accessible to non programmers, and suddenly those tools seemed a lot more than I bargained for.

I'm not sure it's Jira-fication. I think it's mapping effort back to something that has a direct result to the bottom line.

Example: I used to work for a company that basically made slot machines. We needed to produce something called parsheets to give to submit to get our slots certified and to the casino. I was given the project but no manager wanted to give any developers to implement it. No one wanted to give the money to buy a computer with enough power to run simulations to produce the theoretical hold. But this was something we NEEDED to help get our games approved.

You left us hanging: So, what happened?

Reply on news.ycombinator.com