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.
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".
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.
Now this isn’t the sys admins fault at all. The sys admin definitely helped here but the devs still have a broken workflow.
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.
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 :-)
More about this: https://news.ycombinator.com/item?id=25663767
> 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.
Installed update X to prevent risk Y
Wrote script to advance process Z on input A
Etc...
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.
I had a good mentor when I was doing sysadmin. Not quite as formal as this, but the conversations were similar.
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.
If I sysadmin again, I am going to do that. "Why those trains ran on time."
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).
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.
People who specialize will be better at their specialization, but you will be good enough for majority of apps.
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 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 :)]
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.
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.
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.