Drunk Post: Things I've learned as a Sr Engineer has trending with some fantastic discussion on Twitter & Reddit.
What makes it so interesting is the raw and unfiltered message, mixed in with some great humor.
{{< admonition type="Note" title="My Background" open="true">}}
The author of that post comes from a Data Engineer side.
I've been a Database Developer, Production DBA, Cloud Engineer, and other odd hats.
Some of my perspectives is different from the roles I've been involved in.
{{< /admonition >}}
If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.
I agree you fix it!
I believe in continual refactoring and improvement, applying Site Reliability Engineering principles.
Don't kick the can down the street.
Own it!
For beginners, the most lucrative programming language to learn is SQL.
Agree, it's a solid start and often can be done if you are working in a non-engineer role to bring value immediately to your company.
Paying for classes, books, conferences is worth it.
A caveat: a company should invest in the development of their employees, so try to leverage those benefits first.
If people are trying to assign blame to a bug or outage, it's time to move on.
If this is a routine occurrence, heck yes.
Sometimes you can't help but run into politics.
I love drinking with my co-workers during happy hour. I'd rather spend time with kids, family, or friends.
Agreed.
On this topic, companies shouldn't schedule team/company events in employees' off time.
Schedule it during work hours.
Don't impact their family.
The best demonstration of great leadership is when my leader took the fall for a mistake that was 100% my fault. You better believe I would've walked over fire for her.
100% agree. My first week at one of my roles, I broke internalization and required the team to deploy a hotfix to clients overseas.
Release manager protected me during calls and said we had a fix in place. No blame.
I stayed 7 years and would have done almost anything for that release manager.
* those devops guys and gals are* smart. At least those mofos get paid though.
😊 We are making it up just like anyone else, but have to have flexibility in learning and change due to the wide range of things to learn.
Despite focusing on a role in Backend Engineering now, I'm incredibly grateful to have worked in a Development Operations team and see growth with my ability to handle pressure, cross-functional communication, and wide range of technology exposure.
AWS is hard.
Linux is important even when I was working in all Windows. Why? Because I eventually worked in Linux. So happy for those weekend where I screwed around installing Arch.
True. I wish I had started early.
There is a career in purely Windows-based development, but I'd tell anyone starting out, it's better to start with Linux as a choice if possible.
It feels so much simpler overall than Windows with all its API-based management, registry, and lots of complexity overall.
I don't know why I siked myself out for so long.
Linux feels natural as I'm immersed in it more.
I've learned to be wary for ambiguous buzz words like big data.
Agreed.
My inner geek want to play with ML.
My engineer side questions the value for ML in normal enterprise work.
It brings value, but I'd lean towards thinking the majority of businesses not specifically doing large amounts of analytics as a core business aren't going to find quick value from the magic 8 ball.
See Machine Learning Is A Marvelously Executed Scam
When I first started, I was enamored with technology and programming and computer science. I'm over it.
I still love tech.
I think the tendency to tinker and experiment is just in my dna.
The most underrated skill to learn as an engineer is how to document.
I wish this was true.
In my experience, the documentation I've written hasn't brought the value and recognization I thought it would, if the culture doesn't prize this.
I still write & blog, but unless the work culture supports reading first then meeting on something, I've found it's not given the priority it deserves.
The older I get, the more I appreciate dynamic languages. ****, I said it. Fight me.
I started with dynamic languages.
Having started with Go in the last year, I'm finding a happy medium, and seeing that it presents a good development experience.
I'd lean towards something like Go now, even for automation oriented work when possible.
Seriously, I've lost so many hours with stupid typo & type issues in languages like PowerShell
I'm slowly gravitating towards Go for most work, though its verbosity can be annoying compared to a quick PowerShell one-liner.
Titles mostly don't matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That's all people care about.
Fellow engineers couldn't care less about your title.
Titles matter to HR when dealing with compensation and determining rates, so don't ignore how important they are outside of the actual job role.
Compiling some principles and thoughts on my experiences could be a good way to think through key areas I've improved over the years, so I'll probably take a swing at creating my own "Career Advice to Myself" post. TBD