DEV Community: Peter Levine

Software Development - The Bad Parts

Peter Levine — Wed, 25 Sep 2024 17:06:16 +0000

I, much like all of you, love making things. We like to take things apart and figure out how to put them back together. Or, well, at least attempt to put them back together. We then chose this as our career path. We might even be decent enough at it to get paid for it. Much like everything else that becomes a job, we end up getting burnt out and start to dislike it. So lets dissect the bad parts from the good to make a more meaningful career out of it!
The first thing that's incredible about this career path is the human element. Humans make mistakes and we learn from those mistakes. As software engineers are typically pessimistic, you'll be reminded of your mistakes quite often. Software engineers typically spend their days debugging issues and critiquing design. That affords that kind of mindset into our daily lives.
What's so cool about this is that your past mistakes become a tool for others to take advantage of. Take a former tech lead colleague of mine for example. Passionate person who lives and breaths design patterns and software engineering. You know the type, they're constantly in the director's office persuading their agenda, justifying their existence by forcing unnecessary changes.
The platform team created a cli to spin up a local dev environment. So this tech lead went to task immediately. Became a change-agent for the good of all developers in the company. A virtual pillar of light in the dark ages of spinning up your own development environment. Everyone has the same environment eliminating the issues that come with differing operating systems or dependencies or what have you. One could spend unlimited hours talking to different developers in the office the benefit of using such a tool.
What you begin to learn over time as a software engineer is that rolling your own tools tend to introduce complications. Using your experience you shy away from making immediate change so that tools can be hardened and battle-tested. Luckily for me I caved immediately and began to use this tool. Issues abound, but I was able to work through them and even make changes to the tools source. Once things were pretty normal over time I began to simply use it as intended and forgot about it. After a while I began to notice issues. Things weren't working and debugging internal tools is always super easy. Internal tools always include rigorous documentation. CLI Internal tools like include exhaustive help commands along with examples for every parameter. These tools are deeply embedded with package managers for easy update. Or not. Any way, I became the only developer with the issue I was facing. It took the manager of the platform team and I the better part of a day to diagnose the issue and to my embarrassment I needed to update the cli.
As you can guess by now the next few months felt like minutes. I like to reflect back on something one of my previous CTOs would say at all hands meetings. "What gets you out of bed in the morning excited for work?" After over hearing the first time I was being used as an example to keep all of our tooling up to date my drive to be a better dev was never higher. After hearing this one issue in performance reviews because managers totally don't hear something negative once and then harp on it for the next year. What got me out of bed every morning was the knowledge I was being used as an example of how others can be better.
Here's where the bad part comes in. I sometimes like to defend myself and my position. Did the CLI tool mention any deprecations? Did the CLI tool recommend upgrading in a warning? Was the cli tool in an easy to use package manager or was it like every single other internal tool and you had to build the thing yourself? None of that matters or will ever matter. At the end of the day I took a manager's few hours to diagnose an issue that was already fixed.
What were we talking about? Ah, yes, building things. That's what we do. I forgot. That's what we as the builders get recognized for! The things we build!

Sometimes when other people have an agenda, it feels really good to be a part of that change. One great thing that happens as a non managerial or lead engineer is the glory of completing and deploying such a change for the betterment of customers internal or external. Say you have this tech lead that is starting an MVP (minimal (non) viable product(bug riddled barely pseudo code)). You get tapped to be a part of this. Take it forward. Productionalize (Technical term. see also: un-f*ck) it. It replaces an old thing, build upon it, makes it better! Managers are happy! Customers are um, well, they hate it but its better so they'll like it eventually! Then the best thing happens. Tech lead gets tapped to work on another project. Issues poor in as customers start to use it. System design can't handle a feature that was in the old functionality? No matter, you're there to save the day! The rest of the team moves on to other projects but you volunteered for this one. However your team still needs to make progress on this new thing that was moved on to. You feel bad that you can't contribute because you had to work on this other thing. What becomes really slick is on standup management or leads or staff members like to bring something up in general. Like for example "this new feature isn't going away so I don't know why some of you wouldn't expect to fix issues as they arise" Haha! This is surprising to you because you have a team. The team should have items in backlogs or whatever that the team can work on right? That's how this works right? Whomever is on the team can work on any item. Sure. You bring that up with your manager. Turns out that's how it works! "Also why aren't you working on the new thing we have deadlines?! Can you fix these issues or not?" Super cool. Love it.

Often times in your career you get to experience switching teams. With layoffs and condensing team sizes this will start to become relatively normal. Thanks Musk. Sometimes you get a manager that has a hard time explaining definites. They don't like to allow for criticisms to those changes except for their A-Team. With these kinds of managers you'll typically hear about changes through the grapevine. I met with my manager one time after hearing I would be joining a different team from a fellow engineer. I brought it up in our 1:1 and he was like oh yeah, hey, can you start joining this other teams stand ups and helping them out? I was like sure. I then thought that was it, I would temporarily help them out. In our next one on one after attending both stand ups. They mentioned: hey can you stop attending our standups and only attend that teams standup? This was an actual conversation. I liken joining a new team to joining whole new job. You definitely are given a ramp up time on said team, right?
So here we are in 2024. Things have changed. As an engineer you have way more competition. You can be let go for any reason at any time and it turns out there are engineers decentish enough to figure out what you did to keep things running. You're replaceable. There's these new tools that make you even faster at doing the fun part of the job so you can spend your hours doing the other stuff. The even better stuff. The human element. You will write less code and you'll love it! You'll be passionate about it! "You'll enjoy the changes or you'll find you don't belong here" - Actual CTO from actual software company all hands.

"I just want to write software!"

The Story of RemoteInclusive - How we got here

Peter Levine — Sat, 11 Dec 2021 01:09:21 +0000

The first and foremost core value of RemoteInclusive is transparency. We genuinely believe that for a company to claim to be inclusive, they must start with hiring first.

I have been quite lucky in my career in tech to be both a hiring manager and an individual contributor. Over the past fifteen years, I have moved from a web developer, software engineer, senior software engineer, lead engineer, and ultimately engineering manager. Over the past few years as an engineering manager, I have had the privilege and honor to manage some very talented software and QA engineers. Unfortunately, due to unforeseen circumstances of the pandemic and managing a SaaS meant for small to medium-sized businesses. The pandemic ended up hitting the SMB segment pretty hard.

The organization decided to do some layoffs at the early stages of the pandemic. Luckily through some transparency of some of the higher-ups in the company, I was lucky enough to see this coming. Before the layoffs, I worked with my team to do resume reviews. I had my team pick out some jobs they could see themselves working at, and we updated their resume/linked-in profile to target those particular positions. Over the next few weeks, we met quite often to discuss interview processes, pay, policies, and how it seems like we are in the Wild West as each company does its own thing.

One of the most prominent topics of discussion for my team was pay. What should they make in their particular location? What companies should they apply to meet their needs for total compensation, benefits, etc.? When meeting quite regularly, we shared stories of how some positions wouldn't even provide a pay range until the individual completed the interview process. As someone who managed a team of nine engineers and QA, I am lucky to have a lot of diverse voices.

My team consisted of women engineers, people of color, and engineers working outside the United States. Every one of their own stories is quite different. Some of my team have children and don't have the time to maintain side projects. Some engineers are incredibly talented but don't want to spend hours completing unpaid take-home projects outside of working hours. In speaking with my team, they shared that they would decline to proceed with the interview if the process did not meet their personal needs.

I'm thrilled to say that every one of my engineers actively seeking positions landed at organizations that genuinely fit them. The problem was how much work it took to get there. However, what would have been excellent for them was having a site like RemoteInclusive. A job site to answer most of their questions without even getting on a phone or providing their current salary first would have saved them quite a bit of time!

If you've made it this far subscribe to my upcoming producthunt launch! https://www.producthunt.com/upcoming/remoteinclusive

Technical Interview Process Needs to Change to be Truly Inclusive

Peter Levine — Fri, 01 Oct 2021 03:19:50 +0000

Many companies in this current employee-driven market have a technical interviewing process that many find too cumbersome and take way too long. Many are spanning over three weeks long, including likely far too many rounds. This issue is especially evident with the more prominent technical organizations. As a hiring manager myself, I understand that there are no silver bullet hiring process that fulfills every organization's technical goals.

"Let's cut to the chase: At best, whiteboard coding tests for developer job candidates are useless. At worst, they're a hazing ritual that fuels hiring bias." - https://www.forbes.com/sites/forbestechcouncil/2018/05/08/hiring-bias-starts-at-the-whiteboard/?sh=2c286bddb85f

I know I don't speak for all developers, but at least in my bubble, it seems like whiteboarding interviews are a thing of the past. Or at the very minimum it seems like other developers I know will refuse the interview if those coding puzzles via a whiteboard are part of the process. What then, is the right process? I will speak to two processes, one that I personally use and one that I have heard worked well.

The first I will go over is from talking with colleagues. Consider a senior software engineering interview for a product development team. The tech stack was a modern react and node ecosystem with various backend and data-streaming technologies. The process included a take home with a base git project created. Candidates are all given the same base project. The candidates are provided a feature story to add to this project. If the interviewee passes this portion of the interview, the next round will include expanding said project with a developer at the hiring team. This paired programming exercise replaces the traditional whiteboarding with modern practices of actually writing code in an IDE that the interviewee is already used to. This concludes the technical aspects of the interview.

One particular issue that might already exclude some candidates is the take-home portion. What if the absolutely perfect candidate is a parent who refuses a take-home project? What of said perfect candidate is simply too busy to do the take-home? Couple the take home with the necessity to take another half-day off from their current work schedule to join in on the second round of technical assessment. If the interviewee is interviewing with many companies, this may be the Nth paired programming session and take home.

Next is the process that I've come to respect at my current company. While not perfect, it really only requires at most 3/4ths of a day of an interviewee's time for the complete interview process. We phone screen candidates with a slightly technical but not challenging and requiring no prep. This phone screen is used to gauge interest in the problem the organization is solving and the interviewee's passion in what they would like to work in next to ensure the goals of the interviewee line up with the hiring team. We have the recruiter then prep the interviewee with requirements that we'd like to see for a technical round table.

The interviewee presents one of the following; an in-depth problem they have solved, an open-source project they would like to share, or anything technical that they can speak to for about a half-hour. Leaving another half hour of the round table for the team to ask questions and gauge technical capability. We then split off into one on one questions with different facets of the organization. Their peers may go more in-depth into technical questions regarding the presentation.

This process is far from perfect. I find this process returns better results than a take-home for a few reasons. If the candidate was highly involved in the technical aspect of their presentation, it shows in the speaking ability of their project. Secondly, it is not a surprise. As a candidate coming into the process, they know what they'll be doing and will be comfortable on the topic. When doing paired programming or a take-home, the candidate typically has no idea what problem they'll be solving. Coding in an interview is also exhausting. I find it way more exhausting than typical day-to-day coding. One particular common criticism is the worry and fear of public speaking before the interview. This alone is another avenue where a candidate might avoid the interview altogether if they do not want to put up with a presentation.

I think these processes may be a significant first step in providing a more inclusive technical organization. Does either of these processes speak to you as a candidate? Are there inherent biases that I might have missed?

We still have much work to do outside of simply changing our hiring practices, but we become more inclusive if we self-reflect on the interview process first. Things to consider next is our internal biases. Consider this article on standardizing an organization-wide strategy to remove objectivity and compare each candidate based on answers given previously. "Here's the shocking result: The performance of initially accepted and initially rejected students turned out to be the same. Digging deeper, the researchers found that about three-quarters of the difference in ratings between initially accepted and initially rejected students was due not to more-objective measures, such as grades, but rather to the interviewers' perceptions of the candidates in unstructured interviews." - https://hbr.org/2016/04/how-to-take-the-bias-out-of-interviews

It's Okay to Not Be Excited

Peter Levine — Mon, 05 Apr 2021 18:41:17 +0000

A career in software engineering is a career where changes happen very frequently. It is quite common to move positions every three years. It is also very common now for organizations to have N year growth, exit, M&A plans. Change is healthy, however it is also healthy to be skeptical about change especially as it relates to changes in your organization.

"If you're not excited"

Over the past three years of my career I've heard the phrase "If you're not excited then ..." as a term used in meetings or in conversation about organizational change. While that change may indeed be extremely positive for the organization or for the individual or team that the person who relayed this message, it may not be for some. I personally think it is entirely okay to maintain a healthy skepticism of all change. What I don't recommend, however, is to fall into the trap of negativity. This change may be overwhelmingly positive for some of your peers and you should definitely take the time to celebrate with them. Forget about yourself for a bit and make time to celebrate. As a software engineering manager I've found that celebrating my teammates accomplishments is far more fulfilling than receiving praise. Post-celebration, however, you should feel empowered to bring some healthy skepticism to the change.

Change

Every change brings churn. I want you, reader, to take the time to self-reflect whenever your own organization experiences change. Re-think some of the decisions that you might have made about your career. How have you personally changed. Does the organization, post-change, still represent your own values? Like I said, change is healthy. I personally found a passion for empowerment, mentoring and creating goals for my teammates and I never would have had that happen if it weren't for organizational changes that lead to me becoming a manager.

By being 100% excited I think it leads to surprise which in my opinion isn't great for an organization. As a leader if you expect everyone to be excited you're setting yourself up for failure. You will experience churn. Some teams will experience; burnout, loss in morale, and productivity loss.

Positive Vibes Only

Ever since the advent of social media we've been inundated with the thought of keeping a positive only network. Endless articles and tweets of removing the negative people from your lives. Maintaining a positive, always lift you and your friends up mentality.

I have even noticed this becoming a thing in modern job descriptions. I've seen job descriptions mentioning things like: must have a positive outlook, be fun, light hearted etc. etc. Which is fine, I guess, but honestly that's a major turn off for me. It means those qualities are expected of you your entire tenure. What happens if you're having a bad day? Should you be worried about being let go because you're no longer a culture fit?

This leads to something that I like to think of as being "always on". What I mean by this is whether you're in person or over a virtual meeting you are always in this state of maintaining a positive atmosphere. This will ultimately lead to burnout especially for more introverted people. This is even harder for people who might have had trauma in the past. You'll end up honestly being two people, your work persona and your home persona. The more you do this the more I honestly think it will impact your home life.

Problem Solvers

As software engineers we are always putting out fires. We are challenged daily to use our critical thinking skills to solve major problems whether it is UX, bugs, architecture etc. We are by our nature constantly working on problems. As such we tend to think critically about every major obstacle. I personally feel like due to this very thing we sometimes struggle with being ultimately always positive.

Which leads me to think about humanity and our past. Until the very recent past have humans had the luxury to truly and honestly not have to worry about our basic needs. Due to the extreme fast changes humanity is going through due to the progress of technology I feel like we are too immature in tech to fully realize a 100% positive persona. It's hard and exhausting. It's so exhausting that we are feeling the affects virtually with what people are now calling zoom burnout.

Healthy Skepticism

One thing that I personally encourage on my teams are to have a healthy skepticism. As individual contributors, decisions are often made without our involvement. Even in agile / scrum / kanban we're supposed to always be open to change on the regular. By remaining skeptical and asking tough questions, it actually elevates us in a different way. It ensures decisions are thought through. It ensures you have enough evidence that you can defend that decision. You've done enough research that the questions no longer become uncomfortable and whomever makes the decision and their team can feel relieved that the appropriate amount of thought was given to the direction, vision, solution etc.

Comfort Zone

If there's one thing I want you the reader to take out of this, it's to keep asking the tough questions. Put your managers out of their comfort zone. In a modern organization our leaders should also be working for us on our behalf.

What I have always found humorous is that as individual contributors we're always measured for our performance and expected to give daily updates. Typically management does not have to do this. By maintaining an air of healthy skepticism of decisions made on your behalf it takes them out of their comfort zone and also ensures they ensure that those decisions are not taken lightly in the future. Both them and you will grow!

It's Your Career

At the end of the day it's your career. You only have one career. You cannot change the decisions in your past. Use every change that happens to your org or in your life as a time to reflect and ensure that this is the direction you want your career to head. Use your past experience of what questions you asked to guide your future. Make your managers uncomfortable! It's okay to not always be excited!