81–90 of 136 posts
Earlier quoted context omitted.
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
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…
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.
This, 100 times.
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.
Earlier quoted context omitted.
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.
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'.
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.
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 achie…
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 s…
- 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.
There is an outdated term that I find perfectly encapsulates this: "goldbrick."
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 neve…
I feel sorry for you having experienced that culture... this is not normal behaviour for good companies, and they do exist.
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.
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.
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.
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 neve…
> 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.
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.