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 27 days ago [-]
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 27 days ago [-]
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 26 days ago [-]
> 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 24 days ago [-]
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 27 days ago [-]
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 26 days ago [-]
> 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 27 days ago [-]
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 27 days ago [-]
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.
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 27 days ago [-]
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 27 days ago [-]
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 27 days ago [-]
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 26 days ago [-]
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 25 days ago [-]
> 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 26 days ago [-]
> 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 24 days ago [-]
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 24 days ago [-]
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 24 days ago [-]
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 27 days ago [-]
> Finding product market fit usually trumps tech debt
This, 100 times.
XenophileJKO 27 days ago [-]
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 26 days ago [-]
> 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 22 days ago [-]
the issue is that this is not a sustainable approach for projects that are meant to last a long time
XenophileJKO 22 days ago [-]
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 27 days ago [-]
The reason is why they move fast, since there are tons of Juliuses (as per the article terminology) who cannot code at all.
27 days ago [-]
kelnos 27 days ago [-]
> 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 27 days ago [-]
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 26 days ago [-]
> 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 25 days ago [-]
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 27 days ago [-]
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 27 days ago [-]
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 27 days ago [-]
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.
grecy 27 days ago [-]
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 27 days ago [-]
Damn, I saw that dozens of times already, especially in relatively successful startups/scaleups in eu
MortyWaves 26 days ago [-]
I have always called them 0.1x devs. Worked with several exactly as the describe. They provide negative value.
__turbobrew__ 26 days ago [-]
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 27 days ago [-]
> 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.
p4bl0 27 days ago [-]
I saw the end coming miles away, but enjoyed reading this essay anyway as it's well written. I guess I saw it coming in good part because I can really relate to the story, from the point of view of a CS associate professor.
LLMs are a real pain for students on so many levels. These tools can destroy their confidence by being seemingly better than them at first, which also makes these students want to use these tools instead of learning, and then it starts to become a self-fulfilling prophecy. I kind of fear the impact this tech will have on our future. A society mostly full of Juliuses is doomed.
ocschwar 27 days ago [-]
That's why the B-Ark was built.
shever73 27 days ago [-]
This comment made my day. Thank you!
spopejoy 24 days ago [-]
I saw the AI angle right away too but I thought it was maybe SF and Juilius was a cyborg
awanderingmind 27 days ago [-]
Fantastic, hilarious, and too relatable.
Perhaps I am becoming overly cynical as I approach middle age, but it seems to me that this phenomenon exists because the people who have the ultimate decision making powers in businesses are business people. Businesses exist to serve the egos and goals of the people who run them - from their perspective things like technical competence and honesty are often secondary to achieving business outcomes or impressing upper management (it is telling that these are somehow different things). Julius is clearly better at this than the sad programmers who merely know how to code.
I would dearly love to believe that an alternative is possible, but there seem to be powerful incentives pushing the world towards this scenario. For many of us the best we can hope for is a work place that is not too dysfunctional, that respects your personal boundaries while paying an ok salary. I count myself fortunate to work at such a place, while dreaming of other things.
asimpletune 27 days ago [-]
The counter agreement often made is that if there was a better alternative to this then, like a company run by people who understand the fundamentals of what they actually make, then they would outcompete all these lazy bones, self-serving business people. My observation however has been that in fact many such companies have come, they have indeed dominated their competitors, only to later become infiltrated by the same business types they had once trounced.
It’s frustrating to simultaneously be able to perceive this and also do nothing about it. There are a lot of Juliuses out there. Still work doesn’t have to be one’s whole identity. If one happens to be there at the right place and at the right time then awesome. They probably got the experience of their lifetime. But if not then it’s ok! I think we can all do work that we’re proud of still, and it’s probably best to not get too worked up over this stuff. I don’t think Julius has that same option.
Earw0rm 27 days ago [-]
There are two possible outcomes:
- The Julii infiltrate and take over,
- A company run by Julii from the outset comes to dominate the market.
This is because "what we actually make" is a specialist skill, whereas business, sales, operations, financial planning and governance, HR, culture, legal are broadly generalist; and the bigger you get, the greater the important all that stuff becomes, relatively, to core execution on the product and its tech.
Which is not to say the importance of the latter ever goes to zero, but as a ratio it's like 1/log N or so.
epicureanideal 26 days ago [-]
I would argue it’s because the whole economy is basically an oligopoly and there aren’t really enough opportunities for competition. Once a company reaches a certain level, it focuses on pulling up the ladder rather than climbing the ladder.
Earw0rm 25 days ago [-]
"enough" is a value judgment, it depends what field of endeavour we're talking about (and whether the types of bug that proliferate in large firms are preferable to those that proliferate in small ones).
Uber, for example? Dreadful company, but a lot of the small local outfits they displaced were in some ways worse.
Local news media? This seems a more cut and dried case where small is preferable to large, and yet.. small firms are by no means incorruptible, and if the local vested interest succeeds in doing so, history will record only his point of view.
Cars are an interesting one, it looks like the EV transition is going to allow a whole new generation of (mostly Chinese, it must be said) manufacturers to establish a foothold. That's a pretty rare event for modern consumer products, the barriers to entry are huge and in general the reasons why are good.
0xDEAFBEAD 26 days ago [-]
>only to later become infiltrated by the same business types they had once trounced.
Did you see PG's Founder Mode essay by any chance?
>The theme of Brian's talk was that the conventional wisdom about how to run larger companies is mistaken. As Airbnb grew, well-meaning people advised him that he had to run the company in a certain way for it to scale. Their advice could be optimistically summarized as "hire good people and give them room to do their jobs." He followed this advice and the results were disastrous. So he had to figure out a better way on his own, which he did partly by studying how Steve Jobs ran Apple. So far it seems to be working. Airbnb's free cash flow margin is now among the best in Silicon Valley.
>the people who have the ultimate decision making powers in businesses are business people... I would dearly love to believe that an alternative is possible, but there seem to be powerful incentives pushing the world towards this scenario.
Love him or hate him, Elon Musk has done a pretty good job of demonstrating that the market can reward autistic technical leaders who piss everyone off.
Obviously Elon's character flaws are well-documented. I don't think anyone should venerate him. I'm just skeptical that conventional management practices are over-determined by incentives.
awanderingmind 26 days ago [-]
Well, assuming I agree with your premise (I'm not sure I do), what percentage of all the companies in the world does Elon run?
I can also assure you that Julii exist at e.g. Tesla, which employees over 100000 people.
I don't want to start an Elon flame war, but from what I've read I would be sceptical of attributing his business success to technical acumen (which is not to deny that SpaceX builds very cool and impressive rockets, or that the businesses he own employ very smart and motivated people).
eagleislandsong 26 days ago [-]
> I would be sceptical of attributing his business success to technical acumen
If you don't mind elaborating, what would you attribute his success to?
awanderingmind 26 days ago [-]
As I said, I'd rather not start a flame war ;)
eagleislandsong 24 days ago [-]
I understand your reservations. Just to clarify, I wasn't trying to bait you -- I was genuinely curious. But I absolutely get why you'd rather not have this conversation. :-)
johngossman 19 days ago [-]
Read Liftoff by Eric Berger about SpaceX. Musk is not an rocket engineer, but he was great at hiring engineers, motivating them, and willing to take risks in an field allergic to risk (for good reason, people die when planes and rockets crash.) most interesting to me was Musk’s management of their suppliers: he really streamlined the procurement process, which sped up development enormously. He was smart enough to understand what the engineers were doing and make decisions when they deadlocked, but he wasn’t the technical genius behind everything. Nothing wrong with that. In this day of specialization, he wouldn’t be human if he was doing all the technical work.
hklijlyh 27 days ago [-]
[dead]
ChilledTonic 27 days ago [-]
I have to say I became a lot happier in this field once I aligned myself more with Julius.
I think what happens to developers and engineers is that since we have the ability to attune our toolsets very specifically to our needs, we assume everyone can do the same.
This is untrue. Most people live a life of hodge-podge technical solutions that don’t work very well, meaning their expectations for how software should work is supremely low.
Once I understood this I became Julius. Management does not care how or why the software does or doesn’t work - they just want 12 rules for life style platitudes and charisma.
The part about sending Julius to meetings while everyone else worked to fix things particularly stood out. The meetings are useless, but that’s where everyone glad hands. Gladhanders get raises.
The difference is that I like to think I’m still pretty good and doing my job. I’m just acknowledging that pure l33t skills does not a career ladder make. If anything it could even be a hindrance.
Perhaps this is a cynical response.
epicureanideal 26 days ago [-]
> Management does not care how or why the software does or doesn’t work - they just want 12 rules for life style platitudes and charisma.
Which clearly shows that something is wrong in the industry, or how management roles are filled, or how wealth and influence and opportunities are distributed generally.
ChilledTonic 26 days ago [-]
> something is wrong in the industry, or how management roles are filled, or how wealth and influence and opportunities are distributed generally.
And will you be able to fix these issues within your own lifetime? Will you be able to turnover the behemoth of bureaucracy and golf playing managers that has become the technology industry?
If not I highly suggest adopting the Julius mentality.
skulk 25 days ago [-]
"Do you think you will be able to halt this race to the bottom? No? Then start running, I hear it's great down there!"
sourcepluck 27 days ago [-]
Really worth actually reading, very nicely done. I think the point is being made that real Julii exist, and also, that the mechanisms being used to get AI into workplaces and such are the same methods used by the Julii of the world to get ahead as well.
spudlyo 27 days ago [-]
Ah yes, a masculine proper noun of the second declension in the nominative plural. Just one macron away from nailing it ;)
m2f2 27 days ago [-]
;)
pjbk 27 days ago [-]
This was pure gold. I've certainly met many Julii trough my career. The universe spawns and churns them abundantly. It must be fond of them.
bloomingeek 27 days ago [-]
In the non-tech world they're called schmoozers. They were either former athletes, quick witted, good looking, well spoken and/or cockie. Everyone knew they were incompetent, but they seemed to always get away with it because they were likable.
When they were in over their head on a project, they were always assigned someone who could bail them out. Because of this they always increased the work load of others, thus they were loathed. What usually helped us was they would get promoted, then they became useful because then we could control the projects.
bytesandbits 27 days ago [-]
we hired a Julius. Result after a year: Prolific people were laid off, yappers stayed, sales didn't grow, more money was spent than made. Company has 6 month left of runway. Oh Julius why you be like that? Amazing presentations tho. Like watching a movie.
Dansvidania 27 days ago [-]
Wouldn't you agree that the problem in such a situation is not the Julius/Julii, but the managers who hired and misunderstood his/their contributions?
xenocratus 25 days ago [-]
Wouldn't you agree that the problem is not the managers who hired and misunderstood their contributions, but the society who forged them and incentivised them to behave and think like that?
You can basically choose a "scape-goat" at any of these levels, or just choose to accept them all as equal parts of a strange contraption.
Dansvidania 25 days ago [-]
I would not agree. Managers are the fitness function in the system. Workers tend to optimise based on it.
imtringued 24 days ago [-]
Actor-Critic my beloved!
xerox13ster 24 days ago [-]
So then, if we can choose to scapegoat at any of these levels, do we choose to recurse to the base case and say that surely we agree that living in a society based on capitalism incentivizes it and money is at fault, or do we escape recursive loop before getting there by returning early and focusing on something else that’s inconsequential?
hklijlyh 27 days ago [-]
[dead]
dgeiser13 27 days ago [-]
Julius sounds like repeated application of The Peter Principle except he never went past any level of competence because he was always incompetent. Polished but incompetent.
thrance 27 days ago [-]
That's great, I really enjoyed that.
I've met my fair share of Juliuses, both in college and in work. It often really made me question why I even care about what I do.
buggy6257 27 days ago [-]
If this is going to enter our lexicon as a short-name for this type of person, I'll point out that since "Julius" is originally latin derived, the pluralization should follow that of most/all latin nouns, and thus be "Julii".
whatisyourwork 27 days ago [-]
Well, yes. But the blog is an English blog and plural is Juliuses. The rules of grammar apply from the language, not from the word. Sometimes the language inherits the rules from the language of the word. But that's an exception.
Well now we are choosing to inherit a newly contextualised word it's appropriate to discuss what grammar we should take with it
m2f2 27 days ago [-]
Just ask Julius, then....
dredmorbius 26 days ago [-]
As we're a tech site, the plural is clearly Juliuxen.
spondylosaurus 27 days ago [-]
That assumes Julius is a second declension noun. If it were a third declension noun it would indeed be Juliuses.
tmtvl 27 days ago [-]
But in Latin Julius starts with an I. (with apologies to The Last Crusade)
tgv 27 days ago [-]
In the subject, but e.g. 'Surely you're joking, Juli?' or 'I feel surrounded by Julios.' My Latin is pretty rusty, though.
carlosjobim 27 days ago [-]
This is not a comment about the main story in the article, but about a paragraph at the end:
"My boss came to see me. He told me that the team’s productivity was dangerously declining. That we should use artificial intelligence more effectively. That we risked being overtaken by competitors who, without a doubt, were using the very latest artificial intelligence."
This is the oldest scam in the book. A boss will never talk to you if there is any kind of problem with your productivity, they will fire you and that's it. Any boss talking about needing to work harder etc. is only trying to squeeze out some extra juice from workers who are already working perfectly fine.
But the author and his team seem to be willing victims of scammers and exploiters, so what else is to be expected?
johnorourke 27 days ago [-]
> A boss will never talk to you if there is any kind of problem with your productivity, they will fire you and that's it
I feel sorry for you having experienced that culture... this is not normal behaviour for good companies, and they do exist.
carlosjobim 27 days ago [-]
Of course there are different environments. If you work in the public sector you won't be fired unless you break the law. If you work somewhere with a lot of investor money coming in, then your employment is not dependent on your productivity. As long as the money keeps coming in, you're safe. Once it stops, everybody is out, even the hardest workers.
And there's even good companies, where they will give a bad employee a chance to become better.
But in more everyday workplaces you first don't get hired unless you're productive, and you secondly get fired if you're not productive. When/if the boss comes around to threaten about working harder, it's almost always a scam, because if there really was any issue, you'd been fired already. This becomes less and less of an issue the better paid a job is, because at the higher levels people know well if they're good or not.
prmoustache 27 days ago [-]
> But the author and his team seem to be willing victims of scammers and exploiters, so what else is to be expected?
This is just a fictional story meant to be an allegory about AI. I don't understand why people takes it so literally in the comments.
carlosjobim 27 days ago [-]
That's not how I read it. The comparison to AI comes at the end, written out literally.
bnetd 27 days ago [-]
> This is the oldest scam in the book.
Sounds like you were born yesterday.
oddly 28 days ago [-]
Haha, I genuinely laughed, thanks for this gem.
electric_mayhem 28 days ago [-]
At the risk of getting too meta, I feel like lots of folks will get the gist of Julius and check out from the article…
…missing the twist.
So as a TLDR, I’ll say that Julius is a peer of the author who is polished but uncomprehending, often spouting convincing-sounding nonsense.
And here in 2024 we not only have folks like that to contend with, but also have polished AI output being forced at us from every direction.
What a world we have ahead of us with Internet-scale automated uncomprehending nonsense
bruce511 27 days ago [-]
What most people will miss is that "presentation is important ".
As coders we spend a lot of time
And pride on the code. We evaluate our work based on its correctness, elegance, effeciency and so on.
But the way everyone else values it is on how it interacts with the world. We get frustrated when someone with clearly inferior skills perfects the presentation layer.
The solution is not to teach Julius to code. The solution is to understand the importance of what Julius is doing and prioritize adding that to our skillset.
Make no mistake, the 10x programmer doesn't write more code, rather they make their code more useful, more accessible, optimized for usefulness as much as effeciency.
Internalize phrases like "if it's not documented it doesn't exist" and understand that training is more important than creation.
torginus 24 days ago [-]
I have tried this, I've solved problems that were deemed impossible and too expensive to solve. And not only did I manage to solve it technically, my solution was convenient and polished enough to be widely adopted across the company. However when I expected this to be recognized, the following things happened:
- Nothing. Other than my colleagues and immediate boss giving me props, nobody even knew something changed.
- When I tried to promote the stuff I did, I realized that most management a two or more levels up had zero clue what we did, and what our actual problems were. I needed to be like those made-for-TV guys where I needed to present a problem and a solution.
- I realized that most managers' mental model of the team is the check engine light model. If the light is on, the guy who makes it go away is a hero, no matter what he does. If it's not, then it's useless, and possibly fraudulent waste.
- I was often accused of being a pushy self-promoter, sleazily taking credit and overrepresenting what I did.
- Once I kind of got good at promoting things, I realized that doing the work is optional. This is probably the starting point for most Juliuses.
- Once I started getting recoginition, I started getting it from the weirdest places. I once got a shout-out from the company higher ups. When I talked to them informally during the christmas party, they admitted they had no idea what I did, or why it was important.
24 days ago [-]
Bluestein 24 days ago [-]
The check engine light model of management. Well put.-
lmm 27 days ago [-]
> Make no mistake, the 10x programmer doesn't write more code, rather they make their code more useful, more accessible, optimized for usefulness as much as effeciency.
Nope. Generally they push back on the requirements and make only the part that was needed. 10x programmers are much more like the top comment's "Pete" than the article's "Julius"
varjag 27 days ago [-]
Not really. I know it hurts to hear but they are simply better.
The first one I worked with would come in the morning, sit down and code. Then take a lunch break and code some more until late in the evening. He was super prolific, his projects were well structured and followed all necessary conventions. He culled his code mercilessly and rewrote things that were going stale without hesitation. He delivered on time to happy customers.
He wasn't much for chit-chat but was friendly and would explain or help if approached. This was all in a small obscure European company. Now almost three decades later he is in a senior IC position at Arm I believe.
amelius 27 days ago [-]
What I learned from this is that by using an AI, I can have a good career with a salary that is above average.
dgeiser13 27 days ago [-]
I read the whole thing and never saw any twist. What did I miss?
analog31 27 days ago [-]
There might be multiple interpretations. Mine was that the colleague whom management is gaa-gaa about, makes flashy presentations, and seems much smarter and quicker than us, but whose work is usually incorrect and often damaging, is AI.
In Kafka's The Castle, the protagonist is sent two assistants by the local government, and (spoiler alert) they thwart everything he tries to do, and end up killing him.
Noumenon72 27 days ago [-]
I missed the twist also. When he said he was surrounded by Juliuses I thought he meant his other colleagues had gotten to their positions by cheating with LLMs to look like Julius.
Jtsummers 27 days ago [-]
Re-read the last 7 paragraphs, quoting paragraph[-7]:
> On my side, I tried to forget Julius. But, recently, my boss came to me with a huge smile. He had met the salesperson from a company that had amazed him with its products. Artificial intelligence software that would, I quote, boost our productivity! [emphasis added]
Noumenon72 27 days ago [-]
I simply did not follow the transition between these two paragraphs:
> I now have an artificial intelligence software that helps me code. Another that helps me search for information. A third one that summarises and writes my emails. I am not allowed to disable them.
> At every moment, every second, I feel surrounded by Julius. By dozens of Juliuses.
The first paragraph is my situation and I like it, so the second paragraph didn't follow for me. My inner voice had a short mental hitch where I thought "was something missing between those? Should I slow down and stop skimming?" Then my eye jumps to "My boss came to see me. He told me that the team’s productivity was dangerously declining" and I decide "the paragraph before must have been referring to the team members using the AI tools", and I've missed the point of the story.
prmoustache 27 days ago [-]
Julius is the AI.
XenophileJKO 27 days ago [-]
I mean I thought it was a allegory about LLMS right from the start.. way too long winded. Just skipped to the bottom to validate it.
karmakurtisaani 27 days ago [-]
If this wasn't about AI, Julius would have been an excellent PM or mid-level manager.
forgetfreeman 27 days ago [-]
If highly confident bullshit artistry is a desirable trait in any job description the parent org should abandon pretense and pivot to flogging crypto and dietary supplements.
jjulius 28 days ago [-]
cough We're not all that bad... cough
inglor_cz 27 days ago [-]
I'd be interested in seeing a presentation detailing how y'all actually, very good.
jpfr 28 days ago [-]
seconded
jparishy 27 days ago [-]
we should start a club
pimeys 27 days ago [-]
Yeah. Juliuses who understand the code.
JuliusSu 27 days ago [-]
I would like to be included in this collection of Julii.
juliusgeo 27 days ago [-]
I would also.
dctoedt 27 days ago [-]
There are lots of politicians like Julius too.
nis0s 27 days ago [-]
CEOs should be replaced by AI, charm shouldn’t be a factor in decision making.
mandmandam 26 days ago [-]
Charming AIs is totally a thing; only it's called jailbreaking.
xp84 22 days ago [-]
Indeed, I cringe at the insane decisions that an AI CEO might make after being sent multi-megabyte emails of mesmerizing nonsense by a bad actor.
georgeecollins 27 days ago [-]
There are two games in a career, a game of expertise and a game of status. Most people on this forum play the authority game, its in the name. But typically groups of humans only listen to an expert when the expert's ideas are propounded by a high status individual. And by status I don't mean class (in this group I assume I don't have to explain expertise) I mean presentation, appearance, biography, provenance.. Both things really matter with humans.
narag 27 days ago [-]
I've met some grossly incompetent colleagues that were kept in the team just because they were willing to do certain kind of work that we didn't like, but management only pretended to not notice.
As for AI being the new version of this, I don't think so. The effect of this tech is more likely to remove one layer in the hierarchy. But maybe it's your boss, not you, that will get replaced.
rsynnott 27 days ago [-]
> I now have an artificial intelligence software that helps me code. Another that helps me search for information. A third one that summarises and writes my emails. I am not allowed to disable them
Wtf, are places actually making this nonsense mandatory now?!
bnetd 27 days ago [-]
Hey Clau^HHHHDev^HHHJulius, summarize for me how did rsynnott spend most of his working hours for the past quarter. Stack rank against rest of department, and output a cost-reduction strategy as a powerpoint presentation for my next meeting.
jollyllama 27 days ago [-]
There is an outdated term that I find perfectly encapsulates this: "goldbrick."
bradleyy 27 days ago [-]
Thank you for this wonderfully useful word!
dredmorbius 26 days ago [-]
I'd worked briefly with a "Julius".
Unpleasant assignment at a decidedly unethical firm, and frankly often-dodgy industry, my own stay was brief.
Technical masters from a top-tier university, had all the toys, flashy wheels, etc.
But stymied by the most elementary coding tasks.
"Julius" turned up in headlines a few years later charged (and subsequently convicted, sentenced, and incarcerated) for insider trading / securities fraud.
I can find links for the legal case, very little if anything online since.
Dansvidania 27 days ago [-]
My 10+ years professional life in software has seen me both thinking I am Julius and thinking I am working with Julii.
What I try to tell myself is that I am working in a state where I am at best ~75% sure of what I am doing. I assume others are in a similar situation with a varying percentage value.
Mistakes happen more often than I would like (not quite of the IP-less internet caliber, but still) and both when I make mistakes, and other make mistakes, I try to remind myself of this.
I value highly anyone that takes the time to tell me I made a mistake and why, I try to offer the same courtesy when I get the chance.
I only am worried when people _repeatedly_ make no attempt to learn from mistakes and just shrug them off, or worse leave the hot potato to someone else and still get the credit. But I can also see how sometimes we make mistakes and don't even realize.
...more on the topic, I guess, I have stopped using AI tools while coding almost completely
tqi 26 days ago [-]
This is a nice parable, but in my experience, people who see their self-image reflected in this story can be just as difficult to work with. They often view themselves as smart and quietly capable, the unsung heroes keeping things running with little compensation and even less credit, while perceiving incompetence and unworthiness in everyone around them.
These individuals may think of themselves as “nice guys,” but their unwavering confidence in their own infallibility blinds them to the distinction between doing things wrong and doing things differently. They dismiss documentation, consensus building, and communication with non-technical colleagues as wastes of time—then wonder why their accomplishments go unrecognized or unappreciated.
caleblloyd 27 days ago [-]
> My boss came to see me. He told me that the team’s productivity was dangerously declining. That we should use artificial intelligence more effectively. That we risked being overtaken by competitors who, without a doubt, were using the very latest artificial intelligence.
I think this part is real. Developers who can use AI tooling to gain a multiple of productivity boost while still having the domain expertise to correct the parts that AI gets wrong will become much more desirable than ones who don’t.
But it’s not so much like the article states- AI is not itself the employee that managers love and their peers despise. The developer who can achieve extremely high and accurate velocity due to a combination of domain expertise and AI use will be the one that both managers and their peers love. And that organization will seek to hire more developers like that one.
fakedang 27 days ago [-]
TIL I'm Julius lol.
FrustratedMonky 27 days ago [-]
Are you sure? I'm always assuming that the Julius's aren't self aware, they don't know that they are like that. If they know, then they aren't Julius, it would be impossible to act this way if you were aware of it, without being a psychopath.
Maybe that should be the discussion. Is Julius a psychopath, and that is what bubbles to the top of corporate hierarchies.
MathMonkeyMan 26 days ago [-]
I think that on some level, Julius knows. He's just very good at avoiding it.
Jackosas 25 days ago [-]
[dead]
27 days ago [-]
sfjailbird 27 days ago [-]
This sounds made up and actually written by an AI. "I now have an artificial intelligence software that helps me code", can't see anyone working in the field writing like that.
laurent_du 27 days ago [-]
The author's native language is French, not English. The article doesn't sound AI-written at all.
dsr_ 27 days ago [-]
I take it you're not used to people whose primary language is French (or Italian, Spanish or Romanian) writing in English?
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.
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 ;-)
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.
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.
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?
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).
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/
I fear they missed the vocabulary part, which was what I found most valuable.
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.
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.
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.
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?
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.
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.
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.
This, 100 times.
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...
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.
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.
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.
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?
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.
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.
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.
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.
LLMs are a real pain for students on so many levels. These tools can destroy their confidence by being seemingly better than them at first, which also makes these students want to use these tools instead of learning, and then it starts to become a self-fulfilling prophecy. I kind of fear the impact this tech will have on our future. A society mostly full of Juliuses is doomed.
Perhaps I am becoming overly cynical as I approach middle age, but it seems to me that this phenomenon exists because the people who have the ultimate decision making powers in businesses are business people. Businesses exist to serve the egos and goals of the people who run them - from their perspective things like technical competence and honesty are often secondary to achieving business outcomes or impressing upper management (it is telling that these are somehow different things). Julius is clearly better at this than the sad programmers who merely know how to code.
I would dearly love to believe that an alternative is possible, but there seem to be powerful incentives pushing the world towards this scenario. For many of us the best we can hope for is a work place that is not too dysfunctional, that respects your personal boundaries while paying an ok salary. I count myself fortunate to work at such a place, while dreaming of other things.
It’s frustrating to simultaneously be able to perceive this and also do nothing about it. There are a lot of Juliuses out there. Still work doesn’t have to be one’s whole identity. If one happens to be there at the right place and at the right time then awesome. They probably got the experience of their lifetime. But if not then it’s ok! I think we can all do work that we’re proud of still, and it’s probably best to not get too worked up over this stuff. I don’t think Julius has that same option.
- The Julii infiltrate and take over,
- A company run by Julii from the outset comes to dominate the market.
This is because "what we actually make" is a specialist skill, whereas business, sales, operations, financial planning and governance, HR, culture, legal are broadly generalist; and the bigger you get, the greater the important all that stuff becomes, relatively, to core execution on the product and its tech.
Which is not to say the importance of the latter ever goes to zero, but as a ratio it's like 1/log N or so.
Uber, for example? Dreadful company, but a lot of the small local outfits they displaced were in some ways worse.
Local news media? This seems a more cut and dried case where small is preferable to large, and yet.. small firms are by no means incorruptible, and if the local vested interest succeeds in doing so, history will record only his point of view.
Cars are an interesting one, it looks like the EV transition is going to allow a whole new generation of (mostly Chinese, it must be said) manufacturers to establish a foothold. That's a pretty rare event for modern consumer products, the barriers to entry are huge and in general the reasons why are good.
Did you see PG's Founder Mode essay by any chance?
>The theme of Brian's talk was that the conventional wisdom about how to run larger companies is mistaken. As Airbnb grew, well-meaning people advised him that he had to run the company in a certain way for it to scale. Their advice could be optimistically summarized as "hire good people and give them room to do their jobs." He followed this advice and the results were disastrous. So he had to figure out a better way on his own, which he did partly by studying how Steve Jobs ran Apple. So far it seems to be working. Airbnb's free cash flow margin is now among the best in Silicon Valley.
https://paulgraham.com/foundermode.html
Love him or hate him, Elon Musk has done a pretty good job of demonstrating that the market can reward autistic technical leaders who piss everyone off.
Recent viral video of Andrej Karpathy describing Elon's management style: https://www.youtube.com/watch?v=aSiJ4YTKxfM
Obviously Elon's character flaws are well-documented. I don't think anyone should venerate him. I'm just skeptical that conventional management practices are over-determined by incentives.
I can also assure you that Julii exist at e.g. Tesla, which employees over 100000 people.
I don't want to start an Elon flame war, but from what I've read I would be sceptical of attributing his business success to technical acumen (which is not to deny that SpaceX builds very cool and impressive rockets, or that the businesses he own employ very smart and motivated people).
If you don't mind elaborating, what would you attribute his success to?
I think what happens to developers and engineers is that since we have the ability to attune our toolsets very specifically to our needs, we assume everyone can do the same.
This is untrue. Most people live a life of hodge-podge technical solutions that don’t work very well, meaning their expectations for how software should work is supremely low.
Once I understood this I became Julius. Management does not care how or why the software does or doesn’t work - they just want 12 rules for life style platitudes and charisma.
The part about sending Julius to meetings while everyone else worked to fix things particularly stood out. The meetings are useless, but that’s where everyone glad hands. Gladhanders get raises.
The difference is that I like to think I’m still pretty good and doing my job. I’m just acknowledging that pure l33t skills does not a career ladder make. If anything it could even be a hindrance.
Perhaps this is a cynical response.
Which clearly shows that something is wrong in the industry, or how management roles are filled, or how wealth and influence and opportunities are distributed generally.
And will you be able to fix these issues within your own lifetime? Will you be able to turnover the behemoth of bureaucracy and golf playing managers that has become the technology industry?
If not I highly suggest adopting the Julius mentality.
When they were in over their head on a project, they were always assigned someone who could bail them out. Because of this they always increased the work load of others, thus they were loathed. What usually helped us was they would get promoted, then they became useful because then we could control the projects.
You can basically choose a "scape-goat" at any of these levels, or just choose to accept them all as equal parts of a strange contraption.
I've met my fair share of Juliuses, both in college and in work. It often really made me question why I even care about what I do.
The author is running a poll to establish the plural: https://mamot.fr/@ploum/113704470821790664
"My boss came to see me. He told me that the team’s productivity was dangerously declining. That we should use artificial intelligence more effectively. That we risked being overtaken by competitors who, without a doubt, were using the very latest artificial intelligence."
This is the oldest scam in the book. A boss will never talk to you if there is any kind of problem with your productivity, they will fire you and that's it. Any boss talking about needing to work harder etc. is only trying to squeeze out some extra juice from workers who are already working perfectly fine.
But the author and his team seem to be willing victims of scammers and exploiters, so what else is to be expected?
I feel sorry for you having experienced that culture... this is not normal behaviour for good companies, and they do exist.
And there's even good companies, where they will give a bad employee a chance to become better.
But in more everyday workplaces you first don't get hired unless you're productive, and you secondly get fired if you're not productive. When/if the boss comes around to threaten about working harder, it's almost always a scam, because if there really was any issue, you'd been fired already. This becomes less and less of an issue the better paid a job is, because at the higher levels people know well if they're good or not.
This is just a fictional story meant to be an allegory about AI. I don't understand why people takes it so literally in the comments.
Sounds like you were born yesterday.
…missing the twist.
So as a TLDR, I’ll say that Julius is a peer of the author who is polished but uncomprehending, often spouting convincing-sounding nonsense.
And here in 2024 we not only have folks like that to contend with, but also have polished AI output being forced at us from every direction.
What a world we have ahead of us with Internet-scale automated uncomprehending nonsense
As coders we spend a lot of time And pride on the code. We evaluate our work based on its correctness, elegance, effeciency and so on.
But the way everyone else values it is on how it interacts with the world. We get frustrated when someone with clearly inferior skills perfects the presentation layer.
The solution is not to teach Julius to code. The solution is to understand the importance of what Julius is doing and prioritize adding that to our skillset.
Make no mistake, the 10x programmer doesn't write more code, rather they make their code more useful, more accessible, optimized for usefulness as much as effeciency.
Internalize phrases like "if it's not documented it doesn't exist" and understand that training is more important than creation.
- Nothing. Other than my colleagues and immediate boss giving me props, nobody even knew something changed.
- When I tried to promote the stuff I did, I realized that most management a two or more levels up had zero clue what we did, and what our actual problems were. I needed to be like those made-for-TV guys where I needed to present a problem and a solution.
- I realized that most managers' mental model of the team is the check engine light model. If the light is on, the guy who makes it go away is a hero, no matter what he does. If it's not, then it's useless, and possibly fraudulent waste.
- I was often accused of being a pushy self-promoter, sleazily taking credit and overrepresenting what I did.
- Once I kind of got good at promoting things, I realized that doing the work is optional. This is probably the starting point for most Juliuses.
- Once I started getting recoginition, I started getting it from the weirdest places. I once got a shout-out from the company higher ups. When I talked to them informally during the christmas party, they admitted they had no idea what I did, or why it was important.
Nope. Generally they push back on the requirements and make only the part that was needed. 10x programmers are much more like the top comment's "Pete" than the article's "Julius"
The first one I worked with would come in the morning, sit down and code. Then take a lunch break and code some more until late in the evening. He was super prolific, his projects were well structured and followed all necessary conventions. He culled his code mercilessly and rewrote things that were going stale without hesitation. He delivered on time to happy customers.
He wasn't much for chit-chat but was friendly and would explain or help if approached. This was all in a small obscure European company. Now almost three decades later he is in a senior IC position at Arm I believe.
In Kafka's The Castle, the protagonist is sent two assistants by the local government, and (spoiler alert) they thwart everything he tries to do, and end up killing him.
> On my side, I tried to forget Julius. But, recently, my boss came to me with a huge smile. He had met the salesperson from a company that had amazed him with its products. Artificial intelligence software that would, I quote, boost our productivity! [emphasis added]
> I now have an artificial intelligence software that helps me code. Another that helps me search for information. A third one that summarises and writes my emails. I am not allowed to disable them.
> At every moment, every second, I feel surrounded by Julius. By dozens of Juliuses.
The first paragraph is my situation and I like it, so the second paragraph didn't follow for me. My inner voice had a short mental hitch where I thought "was something missing between those? Should I slow down and stop skimming?" Then my eye jumps to "My boss came to see me. He told me that the team’s productivity was dangerously declining" and I decide "the paragraph before must have been referring to the team members using the AI tools", and I've missed the point of the story.
As for AI being the new version of this, I don't think so. The effect of this tech is more likely to remove one layer in the hierarchy. But maybe it's your boss, not you, that will get replaced.
Wtf, are places actually making this nonsense mandatory now?!
Unpleasant assignment at a decidedly unethical firm, and frankly often-dodgy industry, my own stay was brief.
Technical masters from a top-tier university, had all the toys, flashy wheels, etc.
But stymied by the most elementary coding tasks.
"Julius" turned up in headlines a few years later charged (and subsequently convicted, sentenced, and incarcerated) for insider trading / securities fraud.
I can find links for the legal case, very little if anything online since.
What I try to tell myself is that I am working in a state where I am at best ~75% sure of what I am doing. I assume others are in a similar situation with a varying percentage value.
Mistakes happen more often than I would like (not quite of the IP-less internet caliber, but still) and both when I make mistakes, and other make mistakes, I try to remind myself of this.
I value highly anyone that takes the time to tell me I made a mistake and why, I try to offer the same courtesy when I get the chance.
I only am worried when people _repeatedly_ make no attempt to learn from mistakes and just shrug them off, or worse leave the hot potato to someone else and still get the credit. But I can also see how sometimes we make mistakes and don't even realize.
...more on the topic, I guess, I have stopped using AI tools while coding almost completely
These individuals may think of themselves as “nice guys,” but their unwavering confidence in their own infallibility blinds them to the distinction between doing things wrong and doing things differently. They dismiss documentation, consensus building, and communication with non-technical colleagues as wastes of time—then wonder why their accomplishments go unrecognized or unappreciated.
I think this part is real. Developers who can use AI tooling to gain a multiple of productivity boost while still having the domain expertise to correct the parts that AI gets wrong will become much more desirable than ones who don’t.
But it’s not so much like the article states- AI is not itself the employee that managers love and their peers despise. The developer who can achieve extremely high and accurate velocity due to a combination of domain expertise and AI use will be the one that both managers and their peers love. And that organization will seek to hire more developers like that one.
Maybe that should be the discussion. Is Julius a psychopath, and that is what bubbles to the top of corporate hierarchies.