DEV Community: Daniel Kassen

What it takes to be a Senior Engineer

Daniel Kassen — Tue, 07 Dec 2021 20:45:05 +0000

Hello Friends.

I finally did it. Happened about a month and a half ago. I was ✨ promoted ✨ to a senior level engineering position. Want to know the most frustrating part about it? It didn't feel like I deserved it. Yes, imposter syndrome sticks with you.

I started my career as a software engineer five years ago after working a job as a developer at a small startup that just needed hands and thoughts which I kinda see as my boot camp experience.

I started my "engineering" career at a larger, yet still small startup in San Francisco, where I learned a lot, but not enough to become a senior there. I did primarily backend work with a spattering of frontend excursions. I got close to senior at that company. So close that my manager wasn't able to pinpoint anything specific to work on.

I was good enough though to land a job at a larger, public company where I was given a position that was once called senior (but was actually software engineer III). The job didn't feel senior and I didn't feel senior. I've stayed at this company for over two years, learned how things work, started working in the frontend, started planning projects, started running certain meetings, and it finally happened. I got promoted. That's the basic history. Five years. Expect that long.

Now for what actually got me to where I am.

You need expertise in the technology. I have four years of experience as a backend engineer and one as a fullstack engineer. I know databases, APIs, graphQL, react and redux, bash, vim, how to use my IDE effectively, how to test things properly, a bit about AWS, networking, algorithms and data structures, design patterns, architecture best practices.. the list goes on. There's a lot you need to know -- some you'll encounter in your day-to-day, some you need to seek out. I read a lot of books. Things will start to meld together and your thoughts and ideas will become more complex without you even noticing.

You need expertise in yourself. My work ethic has fluctuated over the years, but like the Dow Jones, it inches up ever so slightly over time. You need to learn how to use your time effectively. You need to know your limits, set boundaries, and keep focused on one thing at a time, as much as possible. Time management is a skill you build up over time (is that a pun? not a good one, if so) and I -still- suck at it, but I'm getting better as more responsibility is piled on to my plate.

You need expertise in interpersonal communication. If you've read the 7 habits of highly effective people (if you haven't do it, and read it slowly, and absorb what he is saying), you might recognize that the first two paragraphs of what you need are all about becoming independent. Independent is good, but the real magic comes from interdependence -- working with a team of independent people who leverage each other's strengths to create something much bigger and stronger than they are alone. You need to learn how to communicate your problems, what you know, how you can help, what you need help with. Communication is something I can't effectively teach, it's just something that comes with time and experience. One thing I can advise is this -- listen twice as much as you speak. Not just at your job, but in every aspect of your life. Listen to understand, not to respond.

I probably didn't hit on every detail precisely, because your journey will differ from mine. Like I said, this kind of came together over the course of 5 years, plus the boot camp time. Invest in yourself. Learn as much as you can. Bring value to your team, your customers, and yourself. You can do it, so stick to it.

Thanks for reading.

You're No Imposter

Daniel Kassen — Thu, 24 Oct 2019 23:12:07 +0000

Hello! In this post I will be talking about negative self-talk, the imposter syndrome, where it comes from, and how we can talk ourselves out of them using self-empathy. I will use examples that might be somewhat contrived or exaggerated, but my goal is to communicate how we tend to talk to ourselves, and how we can change the way we talk to ourselves.

The Landscape of Programming

The world of software development is vast and ever-growing, expanding quicker than any one person can keep track of. There are more programming languages than there are commonly spoken languages. People who have been in the field for decades know only a fraction of a percent of modern software. It's very intimidating, to say the least.

Ruby on Rails, a single framework, one I've been working with for years, in which I consider myself an expert (except ActiveScaffold 🤢), still confounds me from time to time. And there's so much more I want to learn, but there's so little time!

The Imposter Syndrome: A Product of Pride

We've all felt it at some point or another. That uneasy feeling that you don't think you're quite at the level you need to be, that there's something missing from your knowledge of software development that you must not let show to your colleagues. The fear of being exposed as a fraud. Imposter Syndrome.

It happens at new jobs quite often. We have peers that appear to be endlessly knowledgeable, that can make us feel inadequate. One of the best ways to make yourself miserable is to compare your abilities and accomplishments to others. We do it all the time and it feels bad. We do our best to hide these shortcomings of ours, to make it seem like we aren't worried about it.

Why do we do it? Well, it's our ego, of course! We have an understanding of ourselves and expectations built on those understandings. We find ourselves, perhaps, at a new position. We did so well in the interview, so we must be that smartest and best candidate they ran into. We can't fail! We can't show that there's something that is difficult, or that has escaped our knowledge thus far. We will accomplish all the things, all on our own! We have an image of ourselves to uphold.

As a brief non-software example, I recently joined a running club. I've been running for a bit now and I felt pretty good about my abilities. Thing is, some of these people have been a part of the club for a while now. Some of them even started the thing. Some of them live and breathe to run. I did my best to keep up, and I tried not to show how tired I was (the big sweat stain on my shirt wasn't helping), and I pushed myself very hard to keep up, until eventually I overworked myself and hurt my foot and was out of commission for two straight months. Why do we do these things to ourselves?

Behold, the sin of pride.

We sit in complete silence during that backlog grooming meeting, listening to our new crew talk about the work planned for this new thing-a-ma-jig. We hear the intern talking about a new JavaScript framework (an example I use because I know h*ck-all about JS) with such familiarity, as if they'd done it for years already, and we don't have the confidence to speak up and say "I have no idea what you're talking about."

We fear being vulnerable. We fear speaking on our perceived inadequacies, because we fear further what our peers will think of us. We're dirty little imposters after all, aren't we?

Negative Self-Talk

We have these inherent biases towards our own greatness. We know what we are capable of and we have done many things of this nature in the past. It should be fine.

But what if we fail? We push to production, as we have done many times in the past, and everything seems fine. But then twenty minutes later, one of the software leads sends us a message saying customers are unable to check out, and it seemed to happen just around the time we pushed our last commits in. And then, the self blame and torment come rushing into our minds:

"How didn't I see this coming?!"

"I am so stupid!"

"Why don't I know this already?"

"I'm such a failure."

"Maybe I'm not good enough for this."

Our fear of vulnerability affects how we project ourselves outwardly, and defines (to an extent) how we communicate with ourselves. We subconsciously hold ourselves to our own built-in standards, and when we fail to meet them, we can treat ourselves harshly for it as if our mistakes are inexcusable. We talk ourselves down and make ourselves feel worse.

Of course, it's natural to feel this way when we talk the way we have been trained. We have our values and we make moralistic judgements constantly without even realizing it. Often the word "should" signals these types of judgements; the English language is rife with these subtly forceful words and it's hard to catch them - but I digress.

Self-Empathy

How do we change the way we talk to ourselves? To begin, we must know how we talk to ourselves. Once we know that, we can start to think about the ways we can change.

The first step is to listen. We must recognize when we talk to ourselves with these negative thoughts, and we must listen to the language and tone we use with ourselves. From there we can start to grasp the emotions that lie underneath. It is important that we listen without judgement to the things we are saying -- to simply observe the thoughts and tone. From there we can understand what we are feeling.

This is what I know as "receiving empathetically". Listening to your whole self with no preconceived notion of how things should be, but rather how things are. It is important to keep in mind that we are humans; we have emotions, and needs, and thoughts, and we do things in line with our values. Sometimes we do things that are not in line with our values, and we judge those actions to be mistakes, and we judge ourselves to be less than perfect, but we must not define ourselves by these moralistic judgements.

Did you push to production and bring the entire site down for an hour? You must be angry with yourself for making such a stupid mistake! Or you could understand that it was caused by a missing environment variable that someone else was mostly in charge of. There was little chance you would have caught that anyway. Next time, if we rely on an environment variable to be present, we'll be sure to check for it next time.

Does the intern know a lot more about a JS framework, or infrastructure concepts than you do? You must be an idiot. Or you're a backend app developer. You simply have a different area of expertise, and if you really want to learn more about those other things, then you can go do that, friend.

The Real Imposter

The real imposter is the voice inside your head that tells you that you are not good enough, that you are stupid and you make dumb mistakes. They judge you, they make you feel bad about things you have done. This imposter's name is **shame, a product of negative self-judgement. We must speak to ourselves in a way that does not make us feel shame. We must make is easier to forgive ourselves for the things we consider to be mistakes. Once we can accept these things as part of our humanity, rather than to be ashamed of, we can start to focus on better things.

Being Content With Yourself

I guess what it boils down to is a matter of contentness with yourself - having the courage to accept failure, and expect it to happen on occasion, but not judging yourself for it. You are you, with all of your achievements and failures, your knowledge and lack thereof, your feats of "success", and your massive "mistakes". Life is a journey and we are all taking our own paths. It makes it harder when we hold ourselves back by letting our thoughts bring us down. We need to accept that we are human, and humans are not perfect.

Don't know something that you think you should know already? Ask someone a "stupid" question. It's fine that you didn't know. Thank the person who answers, instead of feeling silly for asking in the first place -- spread the good feelings you're giving yourself.

Go your path at your own pace, and don't beat yourself up when you fall, because above anyone else, you deserve your own compassion, empathy, and love.

Thank you for reading!

Nonviolent Communication in Code Review: Receiving Comments

Daniel Kassen — Mon, 21 Oct 2019 23:11:15 +0000

This post is about communicating with humans, and sorting through the complexities of our day-to-day lives, such that we start to think about the ways to communicate with others to enrich those experiences.

I decided to write this post because I was reading a different blog post about code review, and what things we should and should not say. The post listed a few examples of comments that could raise negative feelings in the author; comments like "Why did you do it this way?", or "THIS IS TERRIBLE! REWRITE IT!" The one that made me stop was:

"I don't like this."

At first glance, it seems relatively harmless, but it is difficult to communicate tone properly on through text. Not everyone can write down their thoughts and feelings like a Hemingway or Shakespeare, and we all interpret comments in our own way; the impact the reader gains can be completely different than was the writer's intent. Let's spend some time analyzing this comment, and show how it and other comments like it can open into to a rich and fulfilling experience between author and commenter.

We will first examine the four components of nonviolent communication, outlined in the book Nonviolent Communication, by Marshall P. Rosenberg, PhD. We will then walk through a scenario starting with this comment in which the author responds in a nonviolent way.

Before diving in, take a moment to imagine or remember a similar situation and consider how you might personally respond to this comment. What did you say to this hypothetical person? Keep it in mind.

What is Nonviolent Communication?

It is a style of communication devised by Dr. Marshall P. Rosenberg that focuses on the emotions, thoughts, and needs of speaker and listener. We often don't like speaking on our emotions in a work setting, but that's merely a product of our society; one that we need to overcome. We are all humans, we all have emotions, and we all have needs. Being able to communicate those in an open, vulnerable way is at the core of creating real connections, and being able to communicate with one another on the most human level.

There are four main components to nonviolent communication:

Observing events without judgement. This is looking at a situation and seeing what happened literally. This can be difficult, and subtle. One example would be the difference between "Your PR is HUGE!!", versus "Your PR is 1,126 lines!" ("HUGE" is a judgement here).
Recognizing the emotions that the events incite within us, as well as the thoughts that surround those emotions. Recognizing emotions - stepping back from a situation and understandind what we are feeling - takes practice, and we might not have a word to pin on our feelings. Also, it is important to distinguish here the difference between what we are thinking and what we are feeling. We feel emotions, such as happiness, sadness, anger. We think a PR is huge. Here's an example: "I feel like your PR could be smaller" talks about feelings, but contains none. "I feel weary from reading your PR, and I think there is work that can be done to break it into smaller, more digestible pieces" mentions the feeling, and the thought around it.
Understanding the needs that the emotions stem from. We all have needs that we want fulfilled, and our needs are different from those of others. Perhaps the need that might lead to weariness in reviewing a long PR might be the need for simplicity, or brevity, so that we can ensure that the code is well reviewed, and we can feel assured that it will not cause production incidents.
Making a request that will enrich life. After we have identified our feelings and needs, it is now time to make a request of the individual(s) we are communicating with: "Could you break this into smaller PRs that can be individually reviewed?" It is important that our request is one that does not act as a demand in disguise, but relies on the individual(s) to which the request is directed to receive it compassionately, with understanding and empathy, and to fulfill whatever it is we are wanting them to do.

Responding to Terse Comments

Now that we have a basic understanding of nonviolent communication, let's try and understand how we can apply it to our code review, and see the benefits it could have in our thinking.

Focusing back on the comment "I don't like this.", there are four options we can do when we read it. Try to match one of these options to your response from earlier:

Blame yourself. "Yeah, this is bad, maybe I could do it better."
Blame the commenter. "This is an unhelpful comment."
Understand what it is you are feeling and needing. "I am confused by this comment, and I need clarity as to what this person means."
Try to understand what the commenter is feeling and needing. "I see that this part of the code makes you unhappy, what is it that you do not like about it? Could you explain further?"

The first option is full self deprecation and shame. I could go deeper into how our society has trained us to feel shame and how we often speak to ourselves negatively ("I'm so dumb, why did I do that?") instead of being empathetic towards ourselves, but that is a long talk in itself.

The second option ignores the comment, and retaliates. Responses of this nature mean shutting down and not receiving the message compassionately, placing blame on the commenter. This will likely lead to more negativity.

The third option involves empathy towards the self. Instead of responding with a kneejerk reaction, it is important to take a step back and understand what it is we are feeling when we read a comment like this. In my experience, I often find comments like this frustrating because they do not fulfill my need for clarity, or actionability. I would respond to this comment with a request to explain further what it is they don't like, or what I could do to fix it.

The fourth option is empathetic towards the commenter. Perhaps they are having a bad day, perhaps they just got out of a long meeting and are mentally exhausted. You can only guess, and understanding that you do not know where they are coming from when they make such comments is the first step to empathy. We can show compassion towards the commenter, and try to understand their feelings and needs.

A Scenario

Again we look at the comment, "I don't like this." The comment has no written context, and may only be attached to a certain line in our code. Maybe it is localized enough that we can see what they are saying immediately, but maybe not. Let's look at a possible scenario that starts with this comment and opens up into something wonderful:

Author: codes

Commenter: I don't like this.

Author: I see that this part of the code makes you unhappy, but I'm having difficulty understanding what is causing these feelings. Could you explain further, for my sake?

Commenter: Apart from the fact that this PR is over a thousand lines long (yikes), I've seen this method used before and often it has unintended consequences because it's got a lot of unintuitive return values. I don't know if it's being used correctly, and I can't quite see how it will affect the code downstream.

Author: Thank you for this. I see that you are worried about the size of the PR, and that you may not be able to find issues in the logic that could cause bugs in production. Let me tell you that I am also wary of possible bugs; perhaps it would help to ease our fears if we pair on Monday and work through the parts that we think need the most attention? I have more context to share around this that I think will clarify why I wrote it this way.

Commenter: Sounds good. Thanks for understanding.

Notice that in their first response, the author takes none of what the commenter says personally. They made no judgements about the comment, communicated their difficulty, and requested further explanation for clarity.

From there, the commenter opened up. They gave much of what they are thinking. From here we can more easily guess at what they are feeling and needing.

The author reflects back to the commenter what they said to show that their comment was read. They address the feelings they found in the comment and echoed them. They then offer to spend time with the commenter, to resolve the issues present in the current state of the code.

The author could have much more easily just responded to the first comment with, "This is a junk comment", which, as you might imagine, would stir up more negative feelings in the commenter. This could cause the commenter to shut down and not respond at all, skipping over the more detailed review, leading to buggy code shipped to production, and pager alerts at 3 AM Saturday morning. Yikes. Instead, the author took the time to look into themselves and find that the comment was causing confusion, and the conversation opened up by calmly requesting clarity. It is important to note here that you cannot effectively address someone else's needs without first addressing your own.

Conclusion

How did you respond to the comment at first? We have seen now what nonviolent communication is. We have seen one small application of where it can be applied in our daily lives, and how it can lead to better outcomes.

Nonviolent communication is built on empathy, which is something not all of us are accustomed to practicing. It takes time, and energy, failure, and iteration, but using it leads to the creation of a deeper understanding of the people around you, their feelings and needs, and enables is to more easily create stronger connections with them, at a more human level.

Indeed, this post could have centered around writing PR comments in a nonviolent way, and you can imagine there are many more applications we can apply this style of communicating both at work and in our personal lives. If you can think of a time where this method may have helped you, or if you have any questions or are in need of clarification (or have any other needs I might be able to address), please leave something in the comments!

Thank you for reading!