Top stories

For the good of all of us.

(Except the ones who are dead.)

7h agoHN ↗

This is what pretty much every “lifehack” type of tip boils down to, btw lol

I guess I should add "for someone else". In that case it's just bad negotiating skills, but at the same time companies have a lot more bargaining power over individual employees, and it's especially bad in the software industry.

7h agoHN ↗

Only if you add the hours for free and dont punch out when you should.

It's not possible to do everything. That's when your coworker that dedicates every waking moment to the job will outpace you and then set the standards.

The skill to distinguish on whether the extra work will help you get paid more in the future is essential. Developing this skill makes it a bet instead of just working more.

it seems clear to me that one can slack off at certain times, and work hard at the important times, and overall come out about the same (or with less overall work). IMO as a developer in a large corp, if you know the right team to talk to, it can save you MONTHS of work yourself

I do enjoy learning new things and having a generalist approach. But its not for everyone.

I learned this the hard way. I have been training a bunch of 5-10 years experience tech-leads, architects, and what not. But on the job, I realized quite a lot cannot switch context and subject at all.

I've found people who have spent decades on one topic in a very specific vertical. It is amazing how they know EVERYTHING in that and I can listen with my jaws dropped to the floor for hours. Then I will wake up, with that spine-chilling shake all over my body on how patient and dedicated one has to be to be on that straight line their entire life.

The other powerful thing about being able to do everyone else's job is that you, personally, gain a lot of leverage, and in a lot of different ways. Someone else needs a favor? You probably know how to deliver. Something's on fire? You probably know what to do next, or at least who to call, no matter what's on fire today. Someone isn't budging on something? You might not have any bigger of a lever than anyone else, but you probably know exactly where to position yours, and exactly what it'll do when you apply a bit of force.

It's useful.

And then there's times like getting to charge your client $300/hour to drop stuff off at FedEx. Because you can do that and you're here and you'll get it done right -- no one needs to explain the idiosyncracies of this particular deadline or package contents; you've got it.

Even if that's not normally a senior consultant's job.

LOL! My bosses used to tell me that I need to learn to be more `rude` and not just do what others says because I can. I have learnt a lot and one of the biggest is to say NO, in big Uppercase—I can do anything for work but I won’t do that, NO, I won’t do that.

Sometime, I still do and I like the fun and thrill of locking in a hotel room after a meeting and coming out in lot less days these days (pppppsssstt, because of AI) and get into the next meeting showing off what can be done that was discussed 48 hours ago.

You don't do these things because they benefit your boss. (They might happen to, but that's not the point.)

You do them because they benefit you.

Not going to benefit you? There's lots of ways to say no to a back-channel request. Not a back-channel request? Then I guess it's not someone else's job!

Easier said than done. Saying no is not so easy. There's a bit of a weird dynamic that if you could do something that others need help with, saying no can be considered rude, but saying (even if lying) that you don't know how to do it is generally accepted. Usually a boss (or even a colleague) backing in saying no helps a lot.

Also the helping can cause escalation of "demand". First you help with something quick and easy for you, but soon you find "owning" more and more of the task.

It's not dissimilar from the entitled people in open source project bug trackers.

Nice reference

There is also the lowercase no, where you say you'd love to do things, but that it has to go through proper channels and get on the roadmap.

As long as you keep getting the performance review brownie points, because if you don't you are out and it doesn't matter.

No matter how dire things are, the people who can get something done that nobody else can (or on timelines they couldn't) tend to do okay in performance reviews. At least in my experience.

There are easier ways to get a false positive though, if you're open to lying, hogging credit, bus chucks etc. I sometimes wonder if I'm the crazy one for Doing Things Right when I could be spending time with my family instead.

Charging $300/hr to drop off FedEx packages is great until you realize you're the only one who knows where the tape is.

I tend to apply this to myself, within an organization (as opposed to those who like to generically try it all - fair enough). I've always been an enormous fan of touring the organization. Whether I join as a dev, or an exec, I always make it a point to spend some time with product, with support, and with marketing. It ends up providing me a unique vantage point. I encourage others to do the same, and when I 'control' onboarding, make it part of the process.

It's literally the fastest way to have someone get up to speed with the customer profile and product. They can play with it whilst listening in to support calls (if a thing). They can learn about pain points and "hard edges" that as developers we don't always come across.

I've experienced that being knowledgeable of the inner workings is a risk of getting dragged into every projects.

When scheduling onboarding, I try to enable touring without those drawbacks.

any tips on how to go about such things? its occasionally hard to find excuses to go hang out at the other end of the building and talk to another team I dont know much about as a regular developer

I usually asked my managers by framing it to their goals, if agreed they would schedule with other managers.

It's harder during crunch or when everyone is remote.

Always have a folder in your hand when visiting other teams in other parts of the office. Print out some code, a few pages of spec, whatever. Just don't go walkabout empty-handed.

I disagree with the centralization thought. I'm working on a project to create a central AI platform for a very large corporation. As you can imagine, such a large company already has several different platforms made by different branches within it. Each branch has something they are relatively happy with. But corporate sees this redundancy as waste, so they want to consolidate it into one.

The problem with one is the same with any other single source: you are stuck with whatever they offer on whatever timelines they provide. You are sharing this with a hundred thousand other people, so it's not tailored to your use case, but either made as generic as possible, or full of irrelevant features. Both of these cases make it worse for you.

I have often made in house libraries either based on or completely replacing a free equivalent because the free one doesn't meet our needs and has extra complications we don't need. Yes, it comes with its costs, but sometimes it's worth it for something that genuinely meets your needs.

By forcing everybody to use the same common platform, you are either forcing them to work around the mismatch between the platform and their needs, or your are forcing the platform to provide for everyone's needs. Neither is efficient and it harms every other user.

If you are going to make your own, you had better have a good reason for it, but you shouldn't be forced into a single solution for everything - it can end up being more expensive than making a few special purpose applications.

As end user of one such platform, thank you giving me hope that at least some people are at least putting in an effort to make decent. We currently have a very weird mix of features applied to everyone and we are not all quite the same almost by definition.

Nice post, but I would appreciate examples. Anyone has good examples of this, and of the "not like this" section?

4h agoHN ↗

In corporations no good deed ever goes unpunished.

Someone literally said that to me when I did a thing. I'd never heard it before. But I'm careful about the things I do now because as soon as I touch or fix something I'm suddenly the owner of it for the rest of time.

4h agoHN ↗

In case the author reads this : I suspect I agree with some of the ideas (or at least they're though provoking), but the writing does not help.

The comma count is a hint ;)

(I had to parse a few paragraphs several times to get the idea.)

[0] https://en.wikipedia.org/wiki/Serial_comma

Conversely, I found this easy and enjoyable to read.

57m agoHN ↗

I got in the habit of using Oxford Commas[0]. Not everyone loves them, and I sometimes need to go back, and uncomma stuff.

I got in the habit, because it is better for technical specifications. It makes it clear, to which word an "and" applies. I think it makes reading prose a bit awkward, though.

I've noticed that LLMs really don't seem to like using commas, in general.

32m agoHN ↗

Huh, that's close to my own writing style.

But you are right, it's becomes an issue when three sentences make up a 100+ word paragraph lol

"For some reason, many resent the idea of working on someone else’s system, and think of it as charity uncalled for in the workplace. Well, did Intel do Microsoft’s job to help poor struggling Microsoft, or did they do it to benefit from Microsoft’s success?"

It all depends on stock options allocation, no?

I worked for a Japanese corporation, and a big part of their HR policy, was to move staff around the company. It was usually in 1- or 2-year stints (people would spend their entire careers at the company, so they could do this). Eventually, they would end up doing longer stints, where they would specialize.

They would couple this with things like standardized coding and documentation styles, common tools, etc. Training on these standards was a regular thing for all staff.

The idea was that they could rapidly move experienced staff around. It also helped staff to understand how their work was applied in an integrated system (having “blinders” on, is a fairly typical issue, with dedicated employees).

It generally worked, but relied on their particular culture, and introduced a fairly significant amount of overhead and rigidity to the system. It would also mean that it takes a long time to cultivate experts.

Personally, I’ve always enjoyed learning new stuff (still do). I actually enjoy taking on projects that I don’t know how to do. I wrote about it here: https://littlegreenviper.com/miscellany/thats-not-what-ships...

This is what doctors do in Czech Republic - mandatory journey through hospital departments taking about 2.5 years.

In Austria as well, it's called "Turnus".

I think this is done in the USA too.

That's Medicine everywhere

This is also part of the system for doctors in the US, it's called residency. During residency rotations the residents (who have already graduated medical school) go through structured clinical training with patients within each medical specialty, supervised by an attending physician.

I'm always wary of colleagues like that. They start doing everybody's job (worse) and immediately management expects everybody to do the same ("there are no excuses..."), with terrible consequences. From experience, they need to be recognized and isolated soon.

One of the things I hate about my current job is that it's impossible to do this.

Everything is locked behind multiple layers of permissions. It takes weeks to get the correct permissions set up even for my actual job (which I see any time changing roles here, or when onboarding new hires). Getting the permissions to jump in and improve some other part of the system that I don't officially own - even though I might get granted them if I ask nicely, because nobody knows who is actually meant to have what permissions - is so much higher friction than asking the "right" person.

54m agoHN ↗

I worked at a company where you could do it, but some people take fixes as insults to their mother's honour, so all in all probably on a personal level it is best to avoid doing it.

37m agoHN ↗

I’ve only worked in a single company where it really worked out, and it took a massive amount of work to massage egos on both sides of the “fix” (one side sees their hammer tool and wants to fix everything with it, and the other has the mother’s honor issue). You really had to spend time with both parties helping them understand things were a certain way for a reason, but that there were always small changes that could improve things.

Encouraging the inverse of fixing relationship helped both parties as well.

That said, I’ve worked in a few other shops that either had the permissions/compartmentalization shit show as a permanent blocker, or were just completely devoid of a culture encouraging people to care about anything beyond their own career/fiefdom. I absolutely despise both cases.

This was just business as usual 50 to 100 years ago. People started at the bottom and worked their way up. There were no I've-got-a-degree shortcuts because degrees weren't about training for a job, they were about finding out about the world around us. It's interesting that things are starting to circle around, but I doubt any corporation will drop the degree requirements... unless AI CEO's start rejecting all human applications.

As a high school dropout, with a GED, I can relate. Pretty much all of my education has been OJT and seminars/classes.

It's earned me lots of sneers, over the years, but the people that mattered, didn't care. I spent most of my career at one of the world's best optical equipment companies, working as a peer with some of the top people in the world. It was quite humbling, and extremely gratifying.