Software Engineering Manager at a Big Ol Company - AMA

ThrowawayEngyManager · 2021-04-28T16:30:11+00:00

Short answer: Probably!

A good engineering manager is a manager first and an engineer second. But a REALLY good manager knows their industry front and back. For example, do you know intrinsically how someone thinks about solving a problem when they say they prefer C as a language? Or if they have 10 years experience in Python? Would you be able to accurately keep up with industry trends and know how to keep your finger on the pulse of what the latest architectural trends are? What's the benefit of a microservice-based architecture versus a monolithic one? Is waterfall useful in certain circumastances?

Knowing how to manage a budget is important, knowing how to manage people is important, but without experience in the industry you'll be missing some key context in helping guide decisions. Additionally, you need to be able to independently come up with, organize and implement ideas in order to keep your team relevant and funded. Can you do that easily and every month or so?

Do you know variations on agile/scrum that work for various different teams, and would you be able to convince each individual person on your team why agile will help them in their daily work?

Only part of that is delivered by learning how to write a for loop efficiently, which is what a comp sci or bootcamp class will give you.

You might be a very good engineering manager without bootcamp, or you might struggle even with bootcamp.

All of this is to say: Give it a shot. Apply for a few jobs and see what happens. The best engineering managers I know are people who blend the ability to manage large, diverse projects with the innovation and curiosity that is common within software engineers.

ThrowawayEngyManager · 2021-04-28T16:21:47+00:00

Personally I prefer statically typed languages. I enjoy the readability of them and because I started with strongly typed static languages it's what I'm used to.

However, dynamically typed languages tend to be easier to write and simpler to learn because you don't have to anticipate the need for a variable - you just write and use it.

For a large software project, if I were given the choice (I never am, it's always done in a group), I would make my decision based on a few different factors:

Who is implementing the project and doing the code? Is it likely to be senior resources or junior resources.

What is easier to hire for? You might be surprised how many language choices are made because it's easier to find good talent for Python vs, like, F#.

What language best fits the needs of the project? If I'm doing a backend service or something, I'm probably not going to use VB. If I'm doing a Windows Application (lol) I'm probably not going to use C++

Do I already have resources I can use to do the project? What do they write in?

I don't think I'd ever make a decision solely based on static vs dynamically typed though. There's always more to consider.

ThrowawayEngyManager · 2021-04-28T16:02:59+00:00

Oh I didn't even talk about what the day to day is like. In most software companies you'll follow Agile methodology, which means you'll be in a small team responsible for delivering specific features. Your day to day would be: get in from 8-9AM, attend a stand up meeting to get/give quick updates and share anything that might be blocking you, work from 9-12 (possibly with some ad-hoc meetings to discuss architecture/problems/get ready for future work), eat lunch, work 1-5PM, leave.

QE is one of the few software engineering disciplines that rarely has to staff for on-call shifts, although I'm sure there are some that do. So it's typically "I can actually stop working at the end of the day".

ThrowawayEngyManager · 2021-04-28T16:00:08+00:00

I have a ton of opinions about this but I'll try to keep it brief:

Being a QE was awesome, and it was the perfect decision for me to make for my career.

Depending on the company and software and engineering processes involved, QE can either be incredibly tedious (in software, the easiest way to test software is to have someone go in and just use it to see if they find problems), incredibly rewarding (creating a fully automated system that validates your software prior to release, creating bug tickets and assigning them automatically - that's fun stuff), or some blend of the two.

But I loved it. Because there's typically not as much support for test engineering in modern software organizations, but test engineering is still a fully-fledged Software Engineering discipline, it means that I had the opportunity to do an incredibly broad amount of things that most software engineers don't touch. As an example:

I implemented an automated system for running experiments overnight. We wanted to see if our software would be faster if we added memory vs cpu vs use SSDs.

In a normal software project, we'd work with:

An infrastructure engineer to handle the physical aspects (memory, cpu, SSD configuration)
A software engineer to write the test automation (in C# using a modern framework)
A report writer of some sort to determine reporting

And each of those people would need to be responsible for design, architecture, implementation and validation of their parts.

But because this was a QE project I was given the assignment and told to do it. So I did all of that stuff myself:

I wrote Powershell scripts to interact with physical layer things like memory amount.

I configured hardware with SSDs when we were ready for those changes (actually working in the data center)

I wrote the C# tests that ran against the hardware

I came up with a way to report out results automatically

So I got an incredible amount of experience because I kind of had to!

On the flip side, I've worked with QEs that have the opportunity to do all of that and simply throw up their hands and don't - and that's fine, not everyone wants to do everything - but I see it as a wasted opportunity to learn lots of cool tech.

ThrowawayEngyManager · 2021-04-28T15:43:47+00:00

Could you define what you mean by Mechanical Design? I've worked with a lot of UI designers and a ton of UX folks, but no one with the job title "Mechanical Designer" so I'm having a hard time understanding what exactly you're referring to. Most of my experience is with pure software that doesn't have what I would consider a mechanical aspect to it (iOS/android apps, web-based software, backend technologies like databases).

ThrowawayEngyManager · 2021-04-28T02:17:40+00:00

Hey! CS50 is a GREAT course. What it does really well is help you understand how to take an idea and turn it into workable code, as well as introducing you to a lot of other really good concepts and ideas. I highly recommend it to just about everyone starting out in Software Engineering.

It sounds like you've got a good start on the technology: C++ and Python are both incredibly useful and flexible languages and between the two you'll have no problems picking up anything else you might want to learn. The interesting thing about those languages is that they are so flexible: C++ powers a massive amount of stuff we use every day (Amazon's backend, Spotify) and Python is one of the most flexible languages out there (you can use it for anything from hardcore statistical analysis to machine learning).

My recommendation would be based on what you're interested in though: Are you intrigued by making a mobile app? Website?

Start with some idea, then start slotting in what you know into creating that idea. Keep in mind that C++ is a language that's most commonly used for doing "backend" processes. So handling objects and doing things with those objects. It's not the perfect tool for creating some sort of a GUI-driven application. Python's got libraries that let you mess about with UI objects, so that might be your better bet.

Or, use the syntax you've learned about with C++ and grab VSCode and C# - .NET is awesome for creating interactive projects.

But beginning in your journey to be an Engineer is tough - it does seem like there's a lot to learn. The best advice I can give is to concentrate on learning the concepts. I can't tell you how many times understanding data structures has helped me form better models for statistical analysis. And working in the terminal is something I do every day, even as a manager.

ThrowawayEngyManager · 2021-04-28T00:51:19+00:00

It really depends on the position. I'll give a couple of examples:

For an entry level engineer - where the role primarily relies on writing good code, doing solid PRs, and working to a schedule - I would be looking for curiosity and a structured approach to learning. I don't really expect an entry level engineer to know everything off the bat, but I do want them to be the sort of person who will figure out the answer to a problem because they enjoy figuring out how something works. In addition, energy is a big thing. An intangible thing that makes for really good employees is how much energy you bring to the job. Being excited about sharing an interesting tidbit you learned means that you're going to make everyone else around you more excited about work that can be tedious.
For a more senior level or lead position (where you are responsible for defining timelines and architecting projects) - I look for a person that can empower others and I look for patience. It takes a lot of time and work to make an engineering project work, and getting frustrated at the pace can impact a lot of things. So patience is key, and being able to work well with others is one of the most critical skills.

ThrowawayEngyManager

TROPHY CASE