Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Colleague Julius

ploum.net

Post reply on HN
Print view View original

131–136 of 136 posts

Re: My Colleague Julius

#131

Post by torginus »

pyrale wrote: post #75
RalfWausE wrote: post #45

Earlier quoted context omitted.

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, an…

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.

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.

Re: My Colleague Julius

#132

Post by mrngm »

motorest wrote: post #106
intelVISA wrote: post #39

Earlier quoted context omitted.

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'.

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

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.

Re: My Colleague Julius

#133

Post by make3 »

motorest wrote: post #107
XenophileJKO wrote: post #10

Earlier quoted context omitted.

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…

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

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

Re: My Colleague Julius

#134

Post by XenophileJKO »

make3 wrote: post #133
motorest wrote: post #107

Earlier quoted context omitted.

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

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

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.

Re: My Colleague Julius

#135

Post by xp84 »

mandmandam wrote: post #101
nis0s wrote: post #60

CEOs should be replaced by AI, charm shouldn’t be a factor in decision making.

Charming AIs is totally a thing; only it's called jailbreaking.

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.

Re: My Colleague Julius

#136

Post by johngossman »

_t9ow wrote: post #122
awanderingmind wrote: post #113

Earlier quoted context omitted.

As I said, I'd rather not start a flame war ;)

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. :-)

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