Comment by duxup | Hacker News Reader

Comment by duxup | Hacker News Reader

Parent Full thread

First real job I had there was this guy who had one specialization. He was in charge of some software that drove tape drives.

Every outside new manager would come in and in some form or another look down on this guy in some form due to his age and generally not doing "a lot" of tasks and new products.

It took the local VP to come down and regularly high five him after his product git rave reviews from customers (regularly) and make the point every time some manager didn't get it.

That guy's code, documentation, everything was rock solid, and the number of support cases for everything he did was so low that the dude was without a doubt the most productive person as far as income goes. You could sell the product that he worked on and just rake in money with almost no costs after that. Almost everything else had a lot of support costs and etc.

Meanwhile the guys who were doing all the new stuff, sucked at trying to juggle 12 things because it looked good on a resume.

It's similar to the systems administrator dilemma.

Do your job well, it looks you are not doing very much, why are we paying you?

Everything is on fire, it looks you are not doing your job properly, why are we paying you?

I've worked with a few engineers over my career like the person you described and frankly they are worth their weight in gold, been able to bank on their output working reliably and consistently over time is hugely valuable, doubly so when what they do is the bedrock of many other things.

Of course the unhurried, thoughtful person looks like they are slacking and the hurried, frantically working person looks like they are a hard worker.

Fundamentally it's because impact is harder to measure than perception.

> Fundamentally it's because impact is harder to measure than perception.

Absolutely. Another nontrivial variable is the tendency for managers/team leads to get the "credit" for successful work, even if they aren't trying to.

I've had managers before that did nothing but impede a high performing team. Luckily we delivered despite this. But it never failed, the manager would get accolades (often very public) for successfully releases, customer feedback, etc, and would end up promoted up. Meanwhile the team kept doing our thing, getting barely-matches-inflation annual increases and more and more micromanagement from the scrum diehards. Didn't take too long for the team to move on to better things. I have a dream of someday reuniting the super team for a sweet startup idea. Not likely to happen but I can dream :-)

Shoot me the list of these team members. :)

More important than any of the advice in TFA is: know when to leave. Most of my regrets are for staying someplace longer than was wise.

More about this: https://news.ycombinator.com/item?id=25663767

> Do your job well, it looks you are not doing very much, why are we paying you?

> Everything is on fire, it looks you are not doing your job properly, why are we paying you?

Option 3: Everything is on fire, be really quick to respond to your manager and then poke and prod at things in production until it kinda works, repeat daily. This guys a hard worker! I'll have to keep him in mind for a promotion.

And in the process burnout yourself. Quit the job or exit game of life.

It just occurred to me a sysadmin log would be very valuable:

Installed update X to prevent risk Y

Wrote script to advance process Z on input A

Etc...

As a sysadmin, I actually keep a log, but I'm under no illusions that anyone will ever see it but me.

I used to track my tasks in Jira with the thought that maybe my boss would look at it and see what I was doing. Of course he wasn't looking at it so I stopped doing it.

My log is mostly for me to provide a list of achievements to my boss whenever there's a review, or if I'm questioned about what I spend my time on.

I did too. But I never did connect the value points to the admin activities.

If I sysadmin again, I am going to do that. "Why those trains ran on time."

I ask my junior sysadmins / new hires to write a daily log for their first year or so.

What did you do today?

What do you need help with?

What went well?

What was frustrating?

What should we change or fix?

When we get together to talk about their day or their week, these logs are extremely useful. Sometimes they generate tickets, sometimes book or course recommendations, people to talk to, sometimes just conversations.

Nice. Seems like you are doing the work needed to bring them into things right.

I had a good mentor when I was doing sysadmin. Not quite as formal as this, but the conversations were similar.

It would, but these logs can also feel like oppressive and meaningless bureaucracy. A lot of sysadmins are not even good at typing...

It’s one of those things that would probably be naturally suited to voice-activated systems (“Hey Siri, today I updated system X to avoid Y, and I wrote a script to improve process Z on input A” - 5 seconds to say, log saved in the right place, keywords like “updated” and “system X” recognised and formalized into some record, etc), if only such systems actually worked on any word beyond the most trivial (good luck with context-less mentions of pythons, rubies, native-american tribes who somehow serve pages of webs, androids in phones, etc etc).

Honestly, that kind of tool would be useful to a lot of people.

The entries in our ansible git repository are supposed to be that log.

I've been bitten by this.

I once worked at a place where the development process for the Windows version of their product was GLACIAL because there was no way to run the CI scripts locally or even set up a dev environment that could build the product. People actually edited code in a text editor and then submitted it to github and waited an hour for the CI job to build a virtual Windows instance, run updates, install Visual Studio, Oracle, and all supporting software, run the compile and bail with a syntax error :((((((

So I made a Powershell script to install everything from scratch on a fresh Windows 10 or Windows Server system using Chocolatey. The script took about an hour to run, but once it was done you had a Windows box (or VM) that could build the project in 2 minutes at most, or just run the CI script directly before committing. Suddenly it didn't take weeks to fix bugs in the Windows client, and corrupted installs or DLL hell was one "wipe", "run script", "walk away while it churns for an hour" cycle to a perfect dev environment again.

I was fired 6 months later for "not stepping up enough".

Management should clearly see impact and that your work multiplier is higher. Their loss for sure.

Typically, higher leveled engineers have higher workforce multipliers —- their output is measured not only on their own work but how they move the whole team, division, company, or industry forward.

I lived almost the exact same story. Except when I was fired I was told to go work at a bigger company. So I did.

Tbh your achievement sounds like you added a lot of complexity (treating symptoms) instead of really trying to tackle the core of the problem.

I'd like to hear an explanation for what seems to be an awful take. Why do you think this?

If your test loop depends on waiting for what sounds like an end to end test, the core problem is that you’re missing lower level functional/unit tests. Nobody should have to regularly wait for a server to install visual studio and oracle crap just to get feedback on a code change.

Now this isn’t the sys admins fault at all. The sys admin definitely helped here but the devs still have a broken workflow.

This solution was designed to solve the whole package. The script is designed to run on BOTH a CI system and a standalone dev box (real or virtual), giving the same deterministic, stable environment so that everyone is always on the same page (Honestly I'm surprised this isn't done more often).

As a developer, you run the script once on your fresh Windows dev box, and then you can develop, run unit tests, or even run the CI script locally to have confidence that it will actually pass CI when you check your code in (and not overload the server with bad builds). In fact, I did all of my dev work in a VM because it's super easy to tear down and rebuild if I break the OS somehow or introduce an unexpected dependency ("it works on my machine" syndrome).

As an admin, you only have to include this one script onto a fresh Windows image, then run it and save the resulting VM image for the CI server to run (instead of installing everything on every run as part of the build script like they were doing).

The original issue was that everyone was using the CI server AS a dev environment because they couldn't get the project to build on a standalone box (it was tricky to set up, and undocumented, and the build scripts assumed a complicated CI environment). And management wasn't even raising a stink about this, despite the HUGE cost (in a large corporation I can understand this sort of thing falling through the cracks sometimes, but not in a small startup!). I'm actually not a sysadmin (I'm a developer), but I do hate inefficiencies like this enough to do something about it.

I solved a bug at my company that was costing $10k per month. The whole thing was not acknowledged because the leaders were embarrassed and probably afraid of repercussions for not realizing they were pouring that much money down the drain. (this was at a small company). Then I was sidelined by the CEO (a marketing guy) because I wasn't "senior enough" to do the job, whatever that means. I wasn't good enough, but the system I built for them is apparently still running several years after I left and looks the same.

On the other hand, lots of places have people who they _think_ are this guy, and who are actually just a bad dev who is good at building an impenetrable moat for job security...

> Meanwhile the guys who were doing all the new stuff, sucked at trying to juggle 12 things because it looked good on a resume.

This isn't helped by the current trend of trying to hire mostly fullstack developers, also known as hiring one person to do the job of three people. It does almost nothing but incentivize packing resumes to hopefully make the cut and burn people out from switching modes.

Fullstack does not mean that you will burn out. Fullstack can mean 40 hours a week, never overtime. Also, for smaller apps, after you had at least few months of experience with all technologies, it is not difficult to switch modes.

People who specialize will be better at their specialization, but you will be good enough for majority of apps.

The JavaScript fatigue is NOT a myth. [and CSS/layout is really tough, too]

All of that applies to frontend development too.

At the end of the day, some people like Javascrip and CSS. And "full stack" only means that they will work with those, SQL, and some backend language (that may be Javascript too). It doesn't imply anything on the workload, all it does imply is that the place is hiring a generalist instead of specialists.

The last job offer that made me smile was for an AI / fullstack developper. Aka the platypus of software dev.

The problem is pretty simple. Let's say you are cutting-edge in all the technologies that make you very adaptable at time T. You get hired. You decide a stack A/B/C/... for your next project. You get stuck in that project for ... let's say 3 years. (a reasonable time for a project to reach production and have a few real-life iterations). If you are not an assh... who leaves after 2 years (leaving the production/maintenance to others, i.e never having lived the "hell" of maintaining things for real), then you are 3 years-behind in all the technologies that are not in the A/B/C/... stack.

Now, at time T+3, you are ... the obsolete man [for TTZ fans only :)]

Frontend has very few to do with HTML and CSS nowadays. It all has to do with framework choice, the build toolchain, the unit-testing of the front, the server-side rendering vs the client-side, the architectural layers (or bricks) to use on the client-side, SEO, performance, CI/CD, browser compatibility, components lifecycle (yumm, library versions upgrade!).

That guy could perfectly be some tech lead, establishing his rock solid approaches on team of junior 4-10 engineers and delivering rock solid new products.

Not everyone has the disposition to teach and lead.

Before we even get to disposition, some folks simply do not want to do those things.

I didn't say it outright but I picked this guy as an example as ... hey ABSOLUTELY did not want to lead anyone / should not lead anyone.

Very much the high performer type who SHOULD NOT 'progress' to management or supervisor or ... reviewer of any sort.

He was professional, but "prickly". I found the keys to get along with him but a lot of folks didn't have the patience.

If he doesn't want, it is one story.

Another story may be because he may not be promotable to such position because of mentioned "prickly" behavior, which may or may be not just engineering honesty and straightforward approach in contrast to bs(sugarcoating, ass kissing, exaggregating, sweeping dirt under carpet, etc) culture established in many companies.

That VP is my hero. I've seen that story play out too often, but without the VP.

Reply on news.ycombinator.com