Sam Myers

Struggling with efficiently managing your software engineers for your company? Wish you had a way to retain your best engineers and get your projects delivered on time? Let’s chat. I’ve built and run several large teams with the highest retention and efficiency in my divisions.

9

Developer downtime: don’t overwork your devs. It’s memorial weekend and I’m lazily sitting on my porch. My kids keep coming in and out of the house, but get stuck because the sliding door keeps coming off the rails and won’t open. Well, since I’ve got nothing else scheduled for the afternoon I investigate the issue. Turns out sliding doors have a bunch of adjustment screws. I adjust them till the door slides smooth. Left in the broken state my kids learned to hit top left side of the door before opening it. Bringing this back to work, I know customer success teams that have a cheat sheet of these maneuvers. Give devs space to observe, we naturally fix these issues.

15

1 Comment

4 Things You Should Put in Your Daily Dev Log To harvest meaningful patterns from your dev log, you’ll need to capture the same things daily. I’ve been engineering software for 25 years, and I’ll share what I’ve routinely kept in mine. Your context is different, so your list will be also. Just make sure you capture the same things daily. Use this list as a skeleton to start from. It’s easier when you aren’t starting from a blank page! Pull Requests I keep track of every PR I submit, approve, or merge. Almost any work product I deliver or review flows through Git. My lists of PRs serve as a personal task-level kanban board of work in progress that I am connected to. These help me easily reconstruct a story of what I’ve done throughout the week. Personal Interactions I make note of every personal interaction I have, scheduled or otherwise. In addition to these notes, I keep a page for each person, and I link to that page from my daily notes. As I note patterns of interaction with a person, I’ll describe those patterns on their page. Over time I build a library of every person I’ve collaborated with and what we worked on together. Project Actions I keep a running narrative of the things I’m working on. I keep a section for each thing I’m working on. These might be at the product or story level - it just depends. Each time I hit a stopping point or interruption, I make a note of what I’ve been doing and what I plan to do next. Guess what I use to inform my daily standup updates? Perplexing Puzzles I make a note of everything that surprises me. These could be strange program behaviors, blockers, production issues - anything unexpected. As I review these periodically, I ask myself how I can use what I’ve learned to improve my mental models. Hopefully this list helps you get past the starting line. Do this faithfully for several months and see where it takes you!

8

8 Comments

I can't write code at night... Said no engineer ever. Why are companies so focused on having all engineers available during the same hours during the day? Hire contractors to do some of the work during off hours. What could possibly go wrong? They get work done and avoid needless meetings? If you can hire a contractor that has set up a specific technology 100s of times and they can get it done in a day, over asking one of your employees to try to hack it together over weeks, why wouldn't you? Let them do it in off hours!

7

3 Comments

🏎️💨 Making of a Ridiculously Fast™ API client in R. Why my package is **~17x faster** than the community alternatives that call the **exact same API endpoints**. 👇🏽**design choices matter** ✨ https://lnkd.in/ggi_2XyQ

129

2 Comments

An RPG leveling tree for Engineering Managers 🧝🏻‍♀️ You can also check out the SWE and DevOps leveling trees in my previous posts. TPM and QA coming soon.

4

2 Comments

If you follow me, you are probably wondering "What does AMP Grazing and regenerative agriculture have to do with DevOps Engineering?" Both leverage systemic mechanisms to produce desired outcomes. Not only do I use Terraform, AWS, Kubernetes, scripting, tooling, and automation to fulfill business needs, but I also use the mindsets and learning styles of my coworkers, the lifecycles of the stock market and the corporation, and relationships between them to help improve what can improve, so that, as a company, a collection of people, we are more adaptive and resilient. Regenerative farming similarly leverages natural processes to improve farming efficiency and outputs. If you haven't already, make sure to check out Carbon Cowboys' documentaries "Carbon Cowboys" (https://carboncowboys.org/) and "Root So Deep" (https://rootssodeep.org/) to learn more! This post is not sponsored, btw. I think the collective wisdom of farmers combined with the financial pressures we are all facing right now has resulted in an amazing, truly "grass roots" movement!

4

1 Comment

👨‍💻This one’s for the software engineers, you’ve probably been there: staring at a tangled web of code that somehow manages to function despite it’s apparent chaos. It's not pretty, it's not perfect, but it gets the job done. 💡 Here's the thing: messy code isn't always a sign of incompetence. Sometimes it's a testament to the creativity and resourcefulness required to solve complex problems under tight deadlines. 😂 🔧 Sure, we all strive for clean, elegant solutions. But in the real world, deadlines loom, requirements shift, and sometimes you just have to roll up your sleeves and make it work, no matter how messy it gets. #code #softwareengineer #itworks

11

Is your team worthy of having juniors? Having a team with people at different levels of experience creates an environment where different strengths and different ways of thinking combine to produce great work and a humane and fun team culture. There is more emphasis placed on learning, teaching, with teachers learning too! This creates solidarity because good seniors are regularly helping out the juniors, so when they can return the favor, they are that much more motivated to help their mentors. Plus it's a well-proven trope in science and mathematics that young people can often have brilliant, even revolutionary, insights even in the early stages of their careers. Yes they require time, so only healthy, successful teams who know what they are doing can be capable of fostering their juniors. The presence of happy, contributing juniors is a sign of a great team. Hire a junior and start on the path to greatness today!

4

Just one month until my talk at KCDC: "Testcontainers: The Secret Weapon of Modern Software Development". Come listen and learn some cool things about automated testing with Containers! https://kcdc.info #KCDC #Testcontainers #Docker

45

2 Comments

I can’t find it now but our team not long ago had a good laugh at a cartoon panel about a software engineer so exasperated at some syntax heavy quasi-code (Terraform, Webpack, Redux?), they quit and took up wood carving. It was our little joke in the Slacks for a minute. Now that the universe has blessed us with an opportunity for reflection (mass lay-offs), we might revisit that theme a bit more seriously. What does a set of wood chisels cost, anyway? I have been consistently surprised, over a couple decades of interviewing software engineering candidates, at how many are unable to demonstrate real interest in the field. Oh sure, there are platitudes; there’s the performative stuff that is the lifeblood of LinkedIn. But there’s less evidence of internally motivated, quiet, continuous self-improvement. What (software engineering things) did you do in the months since you left your last job? What new things are you currently exploring in the field? If the answer is “nothing,” congratulations, you sound like a normal person. But maybe it also means this is an opportunity to realign if not pivot to find what does spark curiosity for you, what you would love exploring. Maybe more UX programming; or more algorithmic. Few things will make your next job more enjoyable than having enthusiasm for the work.

18

3 Comments

There's nothing wrong with unproven tech or with junior devs. Folks just have to be in the right place at the right time doing the right thing to succeed. Junior devs messing around with cutting edge stuff could pay off big, but is usually too risky. Experienced devs making use of the same tech is how you normally advance the state of the art. Using proven tech is a great tool for people to come into the industry, because they get to focus on what they're trying to achieve, rather than wondering whether or not the tools work. And experienced hands using proven tech is a great way to just get the 80% of repetitive things done fast so you can get to the really interesting parts of the business quicker.

7

Lately, I'm running into an issue with senior devs not being able to pass coding screens. I'm NOT talking multi-day take home projects or leet code style questions that require dynamic programming. I'm talking the equivalent of fizzbuzz. -- tic tac toe in react -- pulling data from a data store in python -- using types in typescript ... Anyone noticing the same thing? How much prep should a senior dev really need to do these tests?

18

36 Comments

SRE graph scrying test: I'm backing up a bunch of files to S3, there's moments where the throughput goes down and moments where it goes up. Assuming no network activity in a way that matters, why would the throughput number be going up and down like this?

17

19 Comments

Woah there, "hiring juniors is about making your entire team better" is exactly the kind of unhelpful, oversimplified headline that needs an A4 sheet of caveats adding. Juniors are a massive investment and the suggestion that simply hiring them will make the team stronger is not right at all. Processes that support the career development of more junior engineers aren't accidental byproducts, they're deliberate. Senior engineers need to be provided the time, headspace, training and support to coach, mentor and develop their more junior colleagues. You know what doesn't work? Hiring juniors into overstretched/under-resourced teams where the seniors are overcommitted and under pressure to meet aggressive deadlines. And I've seen this more times than I care to mention. In the scenario where you've got small teams that are under pressure, and the existing engineers don't have time or headspace to coach someone junior, you are *always* better hiring another senior. Someone who reaches autonomy faster will always be better in that situation. If you hire a junior into that team you won't get better code reviews, more innovation or a richer culture of learning. You'll end up with an under-developed junior who struggles to progress their career, and some seniors who feel like they're doing the junior a disservice by being unable to support them properly. It's horrible. And I've been there. Were we all juniors once? Yep. Should *every* team hire juniors? Absolutely not.

4

There are two types of mid-level software developers out there: First: Those teaching and sharing how to handle thousands or millions of transactions per second (100K tps). Second: Those avidly watching and reading about how to handle thousands or millions of transactions per second. Meanwhile, both are working on systems that barely handle 10 transactions per second on a good day. #ScalableSystem

13

1 Comment

There are two types of developers: 1. Those who always work with their dev tools open 🔧 2. And those who don’t (which is like driving blind) 👀, panic-refreshing and hoping it’ll magically work. 🤞 Sure, it *could* happen... but that’s like fixing a fuzzy TV by slapping it. 😂 Which one are you? Let’s be honest, we’ve all been #2 at some point! 💻 #WebDevelopment #CodingLife #FrontendDev #DevHumor #JavaScript #ReactJS --- This version keeps your original humor but adds emojis for some flair and structure, which helps with readability. What do you think?

10

6 Comments

I have an alternative (well... extension) to this one which is to keep a sheet of all work you do as an employee that means something to you. "means something to you" can be a brag, but it also can be a mistake, or something important you learned. It can be a major launch that you led, or a pesky but important bug that you fixed and nobody otherwise would noticed. Even a critical code review that raised the bar for a commit counts! Then, I take it even further and ask employees to seek feedback from their peers on this list, making sure they have a 360 degree view on their work (did I capture this accurately? do you have other observations on my work that I missed?) Employees that do this find it much easier to get a promotion, because 1/ I have a full list of things they did, 2/ I have a full list of things they grew from, 3/ I have plenty of peer feedback and perspective already documented to support the data. It doesn't write the promo doc itself, but boy, it helps A LOT.

13

3 Comments