[angarg12]

I've met a breed of career min-maxers adjacent to Julius that I have a hard time describing.

Picture this: you join a new team with a senior engineer, call him Pete. Pete wrote the initial version of a new product, and you joined the team to take over and continue it's development. Pete is bona fide genius who can work miracles and he is always in the critical path of each new initiative, you are told.

Once you open the lid of this new codebase you discover that this new product is a half baked spaghetti ball of mud that barely works as the demo that it was intended. With no documentation or tests, it takes you a while to even understand what's going on. Meanwhile the clock is ticking. It took Pete a mere 2 weeks to write this system, why it is taking you so long to add new features?

You try to explain to management the pickle you find yourself in, but to no avail. They fucking love Pete, and won't have anyone criticizing him. He has saved their asses in numerous occasions, and why is it always that others are the ones who can't keep up with him?

So you chug along, paying the price of the mess that Pete made while he keeps moving to even larger initiatives under leadership adoration. He also seems to have a knack to leave ship before his acts catch up with him, and when he decided to leave the job for a promotion and significant raise, management will miss him.

I've seen this behavior more than once and it seems too specific to not be intentional. Let me know if you ever met someone like Pete and how you call such people.

[RalfWausE]

Oh, i know him... it's me!

I do "computer stuff" as my profession for about 20 years and always for rather small companies. I do everything from wiring a network, any level of supported, programming and administrative stuff... oh yeah, and in my current job I sometimes drive a forklift in the warehouse.

I work now for about 10 years for the same company and have built significant parts of their software ecosystem, and in my professional opinion: Its a Rube Goldberg machine fixed and extended with duct-tape, hotglue and tons of wishful thinking. Nothing, absolutely nothing in the system I had to build was carefully planned, implemented or tested. Most new feature requests were handed in by an stressed out boss on a Friday afternoon telling me that we need feature X / solution for problem Y / bugfix Z ABSOLUTELY URGENTLY because something went terribly wrong. Its not uncommon that this visits were the result of some prior hotfix backfiring.

And I build it. And it works.

I have often told my boss that it would be best to drag the whole system behind the warehouse and shoot it to relief it of its misery... but, well, it works...

Perhaps I should work on having this 'Pete skill' of leaving ship for the raise and promotion thing ;-)

[pyrale]

The key issue of Petes is when they don't stay and make sure management knows that it's a prototype that needs more love.

They milk the credit and move on, leaving the next engineer explain to management that what they have is not what they believe they have.

[motorest]

> They milk the credit and move on, leaving the next engineer explain to management that what they have is not what they believe they have.

I worked with a Pete. He was brilliant. He wrote all proof of concepts that drove major flagship products. He showcased them. He proved the concept worked. He delivered with lightning fast time-to-market.

He also made it abundantly clear to management that his proof of concepts required major architectural overhauls to make them maintainable. That was the tradeoff. This was clear from the start.

Managers didn't listened. They could not or would not understand why you'd need to rearchitect a service that was working, in spite of the very creator of said service saying it. They believed, or wanted to believe, that the project was done and over.

The problem aren't the Petes. The concept of technical debt is either foreign or tabu for managers. They have to sell the higher-ups the need to spend more resources fixing something that works. It's bad for careers.

[torginus]

The weird thing is management knows who the Pete-s are (either directly, or they know a guy who knows the guy), and once the awards ceremonies are over, and things start breaking in prod, you can bet you ass Pete's Teams will start chiming.

[bombela]

I don't think you are the same Pete.

People like you acknowledge and understand the engineering trade-offs. Which you might smirk at, but is true nonetheless. If there is only one example of you not being op's Pete is that you tell your boss about the reality of the situation.

The OP's Pete I have met many. It is exactly as described.

[motorest]

> The OP's Pete I have met many. It is exactly as described.

I don't think they are different, or at least that far apart.

I have a couple of Pete stories of my own. The last one I had a manager wanting a year's worth of work released in 3 months to meet nice-to-have deadlines. I explained that it was impossible to meet that requirement, but I offered an alternative solution that delivered a MVP in a couple of months but we would still need a year of intensive manual intervention alongside development work to get the system running. I repeated over and over the technical debt. He accepted the tradeoff.

After I delivered the MVP, that manager completely axed any follow-up development work and replaced it with four more ambitious projects. Now we have engineers wasting a few days of work per month doing manual maintenance tasks on top of project work because actually finishing the MVP is no longer in the roadmap.

Here's the kicker: what would happen if I left the company? Would I be singled out as the scapegoat for the MVP being a mess that's missing critical features? Would I be blamed for the project not working as presented by the manager to higher ups? Would I be vilified by the engineers tasked with doing grunt work for something that could be easily automated if a team worked on it for a few months?

[spit2wind]

This is what John Osterhout calls a _tactical tornado_. It's a programmer who only develops tactically. I find his book, "A Philosophy of Software Design" provides a good vocabulary to think about the technical aspects of this. See Chapter 3: Working Code isn't Enough. It may be enough vocabulary to begin working on the problem without attacking the person.

As for the psychology of such people, I haven't found a single resource. Clearly the system they operate in provides a feedback loop that reinforces their behavior. I'm sure personality, as defined by the Big Five model, plays a part (e.g. orderliness).

[whilenot-dev]

Oh man, I remember the difficulties explaining to management that "but it's working code" is just the absolute minimum requirement(!) for any piece of code and not a real measure of quality - any expectation lower than that, that also satisfies the term "software", just doesn't exist. There is some truly incomprehensible stuff out there to trick the type system into accepting your way of coding, to safe another 2 LoCs, or some assumption where team members didn't want to communicate with each other etc. Specs are hard enough.

As for the psychology: I always assumed that some people just don't perceive the contrast between creation and maintenance as very expressive or strong, the article The Maintenance Race[0] from Works in Progress comes to mind here. That article distinguishes between 3 types: Robin Knox-Johnston, Donald Crowhurst and Bernard Moitessier. Maintenance isn't fun for me, it's just tedious work that needs to be done. The easier and the faster it can be done, the better. There's accidental complexity anyway, and the world sure can be messy, but I'll do my best to keep my produced artifacts in line. My perception to orderliness is probably pretty sensitive, maybe my tendency towards depression plays a role here ("Doing maintenance cures depression" is a quote in the mentioned article above) and I can acknowledge that not all people are like that. But for me it feels somewhat similar as if I would compare real vintage things to things that just have been designed with that certain vintage look. Real vintage has to be accepted, it's history after all, but history just can't be designed and you're better off to work into the time ahead. I'll honor accidental complexity, it feels like history, but incomprensible problem-solving skills aren't somewhat part of it, in my book at least.

[0]: https://worksinprogress.co/issue/the-maintenance-race/

[mst]

I really like that book. A bunch of people I've mentioned it to said there was nothing in there that was new to them and they thought it was a waste of time.

I fear they missed the vocabulary part, which was what I found most valuable.

[YmiYugy]

That sounds like a management error, not a Pete problem. If Pete was told to get a demo done as soon as possible, that's what he did. And in many cases that's not a bad thing for management to tell people. Finding product market fit, usually trumps tech debt. The thing is, that management should know, how time intensive and difficult it can be to turn a cobbled together demo into a production system.

[intelVISA]

Pete's just a rational actor in this scenario, the real issue is management with no insight into the reality of what they're 'managing'.

[photonthug]

Mostly agree, although Pete is kind of a jerk if he’s self aware enough to notice exactly what he’s doing to repeatedly and intentionally exploit this pattern of ignorance in management anyway.

But engineers blaming engineers that benefit from being a rational actor inside the mainstream incentive structure of corporate life is basically a distraction, because it gives management a pass for their mismanagement. Like, you don’t have to know the details, but it’s pretty fundamental to understand / recognize / triage tech debt.

[roenxi]

What choice does Pete have? There is a certain romance in defying management but that sort of move is ... career limiting in multiple ways. Management are not there to be defied.

Persuasion and honesty are great tactics with good managers. With bad managers they tend not to work. Bad managers will demand bad software and only be happy when they find someone to deliver it.

[photonthug]

> What choice does Pete have? There is a certain romance in defying management but that sort of move is ... career limiting in multiple ways. Management are not there to be defied.

Pete's got a choice about whether or not to act with integrity, same as everyone else at pretty much every other fork in the road. If management orders you to do something stupid, ways to act with integrity might include: you can say no, or you can do it under formal or informal protest, or you can do it under the condition that related technical debt is prioritized in a timely fashion, etc. There are usually many options for a proportionate response. Design docs with some formal structure will often increase accountability, or since management isn't reading the code anyway perhaps a bare minimum is a comment for posterity that says "Code written under duress. Senior manager SomeGuy said on SomeDate that this would be temporary and can be rewritten by OtherDate" ?

In terms of acting without integrity, sure it's possible to go through a career/life acting out endless scenarios where you basically enter into a conspiracy with your direct superior to screw the other people at your level and to a lesser extent the company in general, all so that you can possibly go one rung up the ladder and do the same thing again. Setting aside the ethical question of how this effects others, and whether or not this is a soul-crushing and dehumanizing thing for Pete to do to himself.. my guess is that most engineers will avoid this mainly just because they'd find ladder-climbing more boring than problem-solving.

> Management are not there to be defied. [..] Bad managers will demand bad software and only be happy when they find someone to deliver it.

Oof. Lucky that when people talk about engineers working "down in the trenches" or "on the front lines" it's usually just making apps or whatever and not actually soldiering, otherwise the whole "just following orders" thing can get ugly. Bad outcomes may always happen regardless, but it makes a big difference to me whether I'm the one that's responsible.

[motorest]

> Pete's just a rational actor in this scenario, the real issue is management with no insight into the reality of what they're 'managing'.

That's the norm, isn't it? The bulk of product managers aren't even technically oriented, let alone software engineering experts with a deep understanding of their own codebases.

Once I worked with a PM that quite openly stated he had to google what was a frontend and a backend developer and still failed to get a clear idea of what they did. How do you explain concepts such as technical debt to this sort of character?

[mrngm]

Find out their frame of reference, look for comparable concepts in the real world. For technical debt, this scene from Malcolm in the Middle (S03E06) https://www.youtube.com/watch?v=AbSehcT19u0 might be a good comparison.

If you refuse to explain relevant concepts to your PM, as a neighbouring commentor suggests, that increases the knowledge gap between you (or your team) and the PM. I think it's in the best interest of both the team and the PM that they have a shared understanding of what happens within a project. On the other hand, if the PM is not interested in any of those details, that is a sign that they might not be a good fit in that part of the organisation.

[intelVISA]

You don't, PM is mostly secretarial. If the actual line manager doesn't understand domain basics they're managing in name only: a deaf conductor.

Sure it happens often because tech is a very profitable, grifter magnet, but we really shouldn't normalize it nor expect to solve what is ultimately an organizational problem.

[tacitusarc]

It sounds like folks don’t understand that part of engineering is solid technical communication up the chain. Sometimes you’ll get a manager who just wants you to push the thing through and plugs their ears, and that sucks. But in my experience, what managers (and execs, for that matter) want is someone who can do the work AND explain the trade offs in terms of business value.

If you are an engineer with a reputation of getting things done, they will listen to you. They may not always follow your recommendations, but often they have context you do not have.

Admittedly, some managers are just ladder climbing batards who will make bad calls regardless.

[rrr_oh_man]

> Finding product market fit usually trumps tech debt

This, 100 times.

[XenophileJKO]

In large companies I have seen a related pattern. Usually a mid-level engineer that the managers love because they "get stuff done".. meanwhile they are a bulldozer in the code, usually with some "ship-it" buddy green lighting the work.

The reason they can "move fast" is because everyone else is trying to limit complexity, etc. and they are punching holes through the abstractions.

Then turn into your "Pete" when they get promoted...

[motorest]

> The reason they can "move fast" is because everyone else is trying to limit complexity, etc. and they are punching holes through the abstractions.

That's perfectly fine. Your salary is paid by paying customers which are attracted and maintained by improving their user experience. You will never get a new paying customer by advertising that you prevented your abstractions from being soiled.

[make3]

the issue is that this is not a sustainable approach for projects that are meant to last a long time

[XenophileJKO]

Bingo! This is the right answer. It always comes down to how long will the code exist and do you need to be able to sustain high velocity over a long period of time.

If you don't need to keep it very long, then hack the hell out of it. If you are in a startup, hack it.. you don't even know if you have product market fit. If you are in an enterprise and your team is responsible for some aspect of the company.. keep it clean and move fast. As soon as you start snowballing hidden complexity via hacks.. it becomes a tar pit.

[rvba]

The reason is why they move fast, since there are tons of Juliuses (as per the article terminology) who cannot code at all.

[kelnos]

> He also seems to have a knack to leave ship before his acts catch up with him, and when he decided to leave the job for a promotion and significant raise, management will miss him.

This is not a "knack". It's a manipulative skill he has learned over time. A way to burnish his reputation at the expense of his peers. Petes suck.

[cgio]

We tend to underestimate management's visibility in such situations. I had three senior engineers. One was your Pete (names are not real of course), throw him anything and he'll have something half-working in no time. Ugly but enough function to be called a proof of concept. One was the opposite, call him Paul, give him any problem and he would spend his whole life if possible researching every minute detail of the problem, similar domains and patterns etc. The last one, Mary, was the master combiner. She could collect all kinds of information, abstract and deep as in Paul's, quirky, dirty or non-existent as in Peter's and make them into something deeply practical and down to earth. Can you see how one could manage the work between these 3, all with their teams, in a way that everyone felt respected and admired for their approach? Same with the Julius of the post. Management might be aware of Julius weaknesses, but Julius could still bring a unique delivery skill-set that is required in the context of the overall team's work.

[lproven]

> Julius could still bring a unique delivery skill-set that is required in the context of the overall team's work.

I do not know the author of the blog, but this part especially strikes me as a misinterpretation of the point of the piece.

But that's shedding light, and maybe it's not and my interpretation was too narrow.

My interpretation was: Julius is a parasite, who contributes nothing but merely makes the productive members of the team work harder to compensate. He sounds convincing but understands nothing, does nothing, contributes nothing, and not only wastes others' time but also steals their credit.

But you see him as contributing? You see what he brings as being valid and valuable -- is that right?

[cgio]

In my example, the first two would reach next level of maturity when they could appreciate the work their peers do and see it to its purpose.

[tdeck]

I worked with someone like this at my first job out of college, he did build a lot before leaving the team. But what he left behind in our systems was a string of technical decisions that really hamstrung us, like building our core service around the API of an extremely inefficient protocol buffer library he wrote himself, resulting in a service that could only handle 4-5 QPS per node. One of our other services used an application specific enum that for some reason existed in its own separate RubyGem that he published, so in order to update it we had to update the gem and then change the dependency reference.

[resonious]

I'm quite scared of being this. I tick a lot of the boxes: I have a good rep for being fast and management likes me quite a bit. And I definitely have spearheaded things that I've since been pulled away from. I try to counter balance all that by writing docs and sticking around though. I do my best to help those who work on the stuff I was involved with.

[athrowaway3z]

I doubt you are. There is an enormous spectrum, and the parent comment makes it sound all bad.

If you got something working, and are available to answer an email explaining why you made a design decision, then you're already cleared of being a bad Pete.

Pete can't make the perfect product and he shouldn't try to. If it took 2 weeks to make management happy then its a problem you can do "right" in 1 or 2 months. A new dev needs to read up on the problem, what Pete did, what needs improvement, and maybe restart fresh to deliver. Good management knows this.

But a 2-week-delivered project is naturally bounded in scope, and its better off for being 'proven' than whatever OP imagined the right way to do it is.

There are only 3 cardinal sins. Don't destroy/overwrite an existing architecture, don't be a smart/dumb coder, don't do a months long Pete-style yolo project.

[_dp9d]

The last telco I worked at had a project manager like this.

She would take on a dozen small-ish projects (~6 months / $1M), and just jam them through by buying some off the shelf managed solution and using an external contractor who would write spaghetti to run tentacles to everything. She would routinely deliver projects early and under budget, which made her a stand out STAR. No other projects in the entire company were remotely close - normal was double time and budget. Green ticks next to her name, promotions, bonuses, etc.

Once I was invited to a conference call with a dozen people I didn't really know.

Her: We've tapped you as the main support person for this new system we've just deployed into production as part of this new project. I has customers live now.

Me: OK, great. Where's the documentation (there is none). What server does it run on? (Huh?). What credentials do I use to login (what?). Who is managing this SSL certificate? (What?). And so on.

I was told later that was a Career Limiting Move (CLM) on my part, because I wasn't being a team player, and I was adding friction to The Greatest Project Manager(TM).

She did this for at least 50 projects, always getting accolades while creating an absolute shit-storm for support to deal with. As the years rolled on I learned this is perfectly normal for a telco.

[miksak]

Damn, I saw that dozens of times already, especially in relatively successful startups/scaleups in eu

[MortyWaves]

I have always called them 0.1x devs. Worked with several exactly as the describe. They provide negative value.

[__turbobrew__]

Im kindof a Pete.

It is a ying-yang kind of situation where you need people to do the greenfield stuff and just get something working and you also need people who balance that through documentation, rollout, and day 2 operations.

I am in a feedback loop of if what I built sucks I will get paged and woken up in the night, but that only includes operational health and not necessarily “good” architecture and documentation.

I will say that 9/10 times when I cut corners or do something which is hacky it is really only an aesthetics thing and does not affect metrics which matter. The best thing you can do is make things simple and hacky, it leads to quick MVP and is easy to refactor. Complex and hacky is where you get into all sorts of problems.

[The_Colonel]

> I've seen this behavior more than once and it seems too specific to not be intentional.

I mean, why not, this sort of quick delivery is super valuable to companies. But management needs to understand that the solution is more like a prototype, difficult to scale (in features, team) and that's where it is the engineer's responsibility to be transparent.