Appetizers

Starting with some basics.

 Fun Starters

Getting to know the human side.

 Main Course

A quick deep dive into the day-to-day job.

Tell us about yourself and your job.

I have found a niche as a full-stack engineer, meaning I build both the user interface and the servers that support them, with React front ends and various cloud-based backend systems. I’ve worked in this type of role at two companies, both of which had relatively similar technology utilized to build their apps.

Both of these shops also use the Agile framework for software engineering, which prescribes a number of regular meetings, a technical team very involved in determining the vision of the project, and a deemphasis on ‘deadlines’, and a decrease in focus on long term plans, in favor of short term, more adaptable ones.

How did you end up in your field? What do you like about it?

I first got into programming as a middle schooler, borrowing one of the textbooks on C++ from a local library. I have come a long way since and (thank goodness) no longer work in anything C. I stayed interested in CS, and made a career out of it, for twofold reasons.

First - I’m good at it and I plainly enjoy it. The feeling of getting a piece of code to work as I intend is like solving a difficult math problem - utmost satisfaction. Secondly - programming is an act of creation. Writing code, in my view, is the purest act of creation there is. While a sculptor “finds the statue already in the block” of marble, programming conjures order and structure out of chaos and emptiness. While I am not a particularly artistic person, I believe all people have creativity within them, and programming lets me express that.

What does a typical morning look like on the job?

All of my teams start with a 15-minute “standup” in the morning. The standup is part of the Agile framework, at which each team member shares what was accomplished yesterday, what is planned for today, and any obstacles blocking progress.

After this, the day becomes a lot less regular. Typically we put any planning type meetings around here, but it varies by team. We will each work on our own tasks in the code, keeping in touch through Slack, with impromptu meetings for any technical decisions or technical design reviews that need to be done. The exceptions to this are Mondays and Fridays. On these days, rather than have a standup, we have, respectively, an all-hands planning meeting (including our business partners and design team), and a demo session, at which we show off what we have built over the last week.

Cool, then what does a typical afternoon look like?

Afternoons look much like the free period in the morning. There are not many regularly recurring meetings, but often we will have impromptu ones between the developers.

When not in meetings, I will program in JavaScript or Java, working on either a web application or an API. I would estimate this programming time is roughly 1/3 actually writing code, and 2/3 reading documentation, designing the solution, writing tests and more documentation, and debugging. Again, the exception is biweekly Friday retrospectives, at which we look back on the former two weeks and discuss any improvements we can make to our team and its processes.

What types of projects and meetings are you involved in?

As a professional software engineer, I spend my time split about halfway between directly programming, and ancillary tasks including planning, technical documentation, mentoring, and coordinating with our business partners.

We have a number of regular meetings called “Agile Ceremonies”, including the aforementioned standup, retrospective, etc. The vast majority of software development teams today are organized as these “Agile” teams, which I encourage you to look up for a better explanation than I can provide, but it generally implies project-based work where, rather than plan out the entire project at the beginning, only high-level details are scoped out and as the project proceeds, detailed work is planned just ahead of the work that’s actually accomplished.

Who do you collaborate with within meetings and projects?

My current organization uses cross-functional teams comprised of a number of full-stack software engineers (currently 3), paired with a number of product owners and designers. The product owner is sort of our liaison to the rest of the business and coordinates priorities, business rules, etc for us.

The role of the designer is, I think, self-explanatory. This team works together to scope out the work for the week at our Monday meetings and works together to ensure that we are always moving forward toward a product our customers can actually use. Having an integrated team like this ensures that us developers aren’t sitting on our hands waiting for designs to build or business approval to build them and keeps us all in touch with the pressures coming from all of our various stakeholders.

 Dessert

Now for some juicy insights in the tea room.

What's the most challenging thing about your job?

In non-COVID times, I think the answer to this question is changing business priorities. It is not uncommon for us to near completion of some feature, only for our business partners to decide that some other feature needs to take priority. This results in work that appears to be going slowly because we aren’t getting features all the way to production and an excessive amount of context switching, which is already an obstacle when you have as diverse responsibilities as a full-stack engineer does.

What are some characteristics that can help someone succeed in your role?

I have found that the most significant predictor of success for software engineers is how capable they are at problem-solving - by which I mean they can look at a long stack trace or error, separate the signal from the noise, and find the relevant part - either a file name to dive into the code or an error code that needs to be googled.

Despite the amount of time spent on it in accredited CS programs, algorithm knowledge has been rarely used. Familiarity with design best practices and patterns is, however, tremendously important. “Leetcode”, while often used to filter applicants, in my view has no relevance to actual skill at building and supporting a production-grade application.

Any advice on how to stand out and get hired for those just starting off?

Work on some of your own projects! It doesn’t have to be anything crazy impressive. Make a multiplayer battleship web game that uses one or two services on AWS, Azure, or GCP and you will be miles ahead of most starting engineers.

What's something that surprised you about your job?

The most surprising thing to me has honestly been how freeform it is. After so many years of academic CS, where assignments are “accomplish this exact task with these exact parameters with this exact tool”, it was surprising to go into the workforce and have generally poorly defined inputs, outputs, and tools to accomplish them. It takes some paradigm-shifting, but it is actually wonderful getting to decide for yourself what sort of interface your code should expose, what sort of database systems you want to use, what language you want to use, etc.

What do you see your next step being?

I suspect in 5 years I will have moved more toward the management side of things. While I love programming, I think my own personality and talents are maximized in interfacing between a lot of people, something which you don’t get that much of in a typical programming job.

While programmers don’t work in isolation by any means and being able to work with a team is incredibly important, there often isn’t much interaction with people beyond your limited project scope.

Any last thoughts, advice, or recommendations for someone who wants to do what you do?

Study agile. Study design patterns. Build a demo app or two. And feel free to get in touch!

 Drinks

Chat more over coffee or tea?