Live data from Hacker News

My Colleague Julius

ploum.net

51–60 of 136 posts

Re: My Colleague Julius

#51
post #4

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…

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.

Re: My Colleague Julius

#52
post #43

Earlier quoted context omitted.

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 sol…

> 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"

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.

Re: My Colleague Julius

#53
post #4

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…

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 sing…

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.

Re: My Colleague Julius

#54
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.

Re: My Colleague Julius

#56
post #4

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…

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 sing…

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/

Re: My Colleague Julius

#57
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

Re: My Colleague Julius

#58

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.

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?
Post reply on HN