DEV Community: Callie, horse boy

How to become a better engineer

Callie, horse boy — Tue, 26 Apr 2022 18:22:39 +0000

This isn't the kind of post you probably think it'll be.

Or maybe it will be.

I've been reflecting daily on white boarding (I can't imagine why) and the reactions from the community to that. I've also been reading lots and lots of "career" oriented books (Being Geek, So Good They Can't Ignore You - which if you've read this, you know precisely where this post will go, and Communication for Engineers), and it's lead me to a lightbulb.

And that's where I'm about to list off a few hot takes.

Surgeons don't do surgery in their spare time

First, let me start this: I don't believe in requiring engineers to pursue their own full-blown "personal projects" on the side of an actual day job. Companies that require an application by submitting a github repository are doing it wrong.

Nonetheless, I see many people cite that surgeons aren't expected to do surgeries on their spare time. However, this misses something pretty important: surgeons read medical journals in their "spare" time.

I view programming as an art, speaking as someone who approaches their music and painting as sums and patterned.

And that's how I believe you leverage becoming a better engineer.

Becoming better at what you do takes work, practice, and research. Lots of it.

Deliberate practice

When I played guitar, I didn't become better by playing Greensleeves over and over. Sure, I enjoyed the song - its familiarity, and the fact I could almost sing along to it. When I painted more, I didn't become better by sticking only to the familiar; I forced myself just outside of my comfort zone a little bit at a time.

As I work through LeetCode problems, I've noticed a similar trend. I become a better engineer when I'm preparing to leave my job because I'm pursuing deliberate practice. I'm pushing myself to look at these completely random problems that I would never otherwise solve, and it's forcing me to be both uncomfortable and creative at the same time. (This is why I view software engineering as an art; it acts as a creative pursuit).

Sure, this isn't going to affect how I align a link on a page. But that's also not a difficult problem for me at this point in my career. Instead, this is going to affect how I solve the other problems: how to access elements on a page. How to handle mega data sets. How to better create a system.

If you want to be a better engineer, a blog post like this won't do that for you. Working at Amazon or Microsoft or Google won't even necessarily do that, either. You don't need to dedicate your entire spare time to creating the next bit app.

You need to take an hour a day (or at least, most days) and push yourself. Do those LeetCode problems. Look at that documentation for something you're not familiar with from your preferred language. Anything you view as hard, or difficult to understand - that's what you should focus on. That's where your growth lies.

Even if you're not whiteboarding soon

An hour can be a lot when you've a family or other obligations. I certainly don't always have a ton of hours to spare, either.

I also don't recommend fitting this in before bed; that makes it much more difficult for folks my own age to be able to perform this deliberate practice, but it'll also make it harder for you to sleep. Just a friendly bit of advice on that one.

So how do I fit it in? I don't have kids (yet). But I do it with my morning coffee. Take time away from your email at work; I'll bet you could get an hour out of that. Take an hour away from Reddit. Stop reading this blog and do it. If your boss doesn't like you working on engineering problems rather than browsing the internet, it's probably time to find a new boss, anyway.

What it feels like

The more I do deliberate practice, the easier it becomes.

Not.

No, especially as a person with executive dysfunction, it's very hard. The first ten or so minutes, my brain screams at me. You're too stupid to do this. This is too far beyond you. You won't get a GOOD answer.

The brain's not just a liar, it's a damned liar.

Consider the way an athlete pushes their muscles. I'm sure all of us have had muscle fatigue before; that's what you're doing here. You're taking your head's meatlump and pushing it just beyond its limits, and it's going to hate that. Stretch it with an easy warmup; get it focused.

You can do this.

After those first few minutes, after you've been able to focus up, you'll begin to make progress.

It doesn't have to be a lot of progress. Maybe you still end up looking up a solution toward the end; that's fine. You'll remember this and do better the next time. Maybe you'll come away with only a little more understanding, or two lines of code written.

That's great. I'm genuinely proud of you. This is how you improve.

You don't have to start out "smart"

Frankly, we don't know how intelligence actually works. Richard Feynmann, famous physicist with accolades in quantum physics - scored a 125 on his IQ test in high school. That's not genius level at all (albeit, still high), and yet, this man won a Nobel in physics.

I don't trust IQ tests. We all know they're riddled with issues. But more importantly, we don't know how it works.

I very much believe that you can make yourself "smarter" (whatever that means). And I believe that it's all in how we apply ourselves.

Discipline

I have autism that mimics the symptoms of ADHD.

It's really hard for me to perform deliberate practice, so I know where many of you are coming from.

You're not a failure if you can't do this daily. What's important is to try.

You've got this.

Imposter syndrome ain't always on you

Callie, horse boy — Fri, 12 Mar 2021 19:11:00 +0000

I stared at my IDE, my brain contorting in more painful poses than I imagine I would if I did yoga. I'd been in front end for years, and I had never seen such a convoluted means to create a simple functional React component.

I swapped my window over to Slack, and made a group DM with the other three people on the team that I'd seen had touched that particular file. "Hey, why are our components like.. three levels deep?" I'm serious - it looked like to create a very simple container component, a series of template components had been made over a function that then called the actual design library itself.

"I have no idea," one coworker replied. "Honestly, if you don't want it written that way, please fix it."

We went back-and-forth for a few minutes, and I finally vented out, "I cannot stand code bases like this. I just don't see why this was written so over-the-top convoluted. It's beautiful, but how are we supposed to maintain this?"

"I'm so glad you said that," another coworker replied. "Seriously. Seeing this code made me feel like I didn't deserve to be a front-end engineer here."

My jaw dropped. A lightbulb went off somewhere in the goopy carbonara my brain had become over the last some-odd hours of work.

It's not just about you

Imposter syndrome isn't just because of some flaw in our brain chemistry. It's not just from how we speak to each other as engineers, or because we spend five hours debugging broken code that turned out to have a variable mistyped. It's because we lead ourselves to believe that extremely complex code somehow trumps the more simplistic code that gets the same job done.

I've been reading and even tweeting on imposter syndrome for years - in particular, relating my experiences as a femme-presenting human in tech for the last 12 years. For an embarrassing large amount of that (at least 11 years), I thought myself somehow unworthy for my pay grade, title, and position at a big company. Sure, the other factors certainly don't help - my horrid, autism-driven anxiety, the way that past managers or coworkers have treated me, and of course, the society that we live in. But it just hadn't hit me that complex code isn't just a pain to maintain: it hits you (general you) right in the metaphorical Achille's.

We gotta fix this

As with everything discussing mental health or our industry's inherent imposter syndrome, we have to work on ourselves to encourage ourselves to not just do better, but to also "fix" this. Because, look at it like this: imposter syndrome isn't about our pride or ego as developers. It's a very real issue that drives people from our field, and that inflicts extremely real harm on our community as a whole.

Going back to this specific topic, I don't perceive all complex code negatively. For example, I have no prior knowledge or experience with RxJS, and much of the code I'm now working with uses that. At first, I felt pretty resistant to using it because I didn't see why we wouldn't just use Promises. This would have caused me to simply not learn that library out of my own idiot pride, and that would have been a mistake because I didn't know the reasoning behind RxJS. In addition, having layers over your components - as per my earlier example - isn't always an issue if it means that you're making those components much easier to reuse.

However, complex code leads to a myriad of other issues. If you leave the team, you probably didn't document it well, and now your team's shot in the foot trying to maintain your brain zombie. In the case of RxJS or Promises, you likely don't even need an additional library for simple ajax calls. Adding that not only adds weight to your application, but another, additional learning curve for future developers to work on it.

And what about bugs? I'm sure plenty of people on here love video games as much as I do. The more complex your code happens to be, the harder to change it. Video games are notorious for this - adding one inventory slot can go as far as to suddenly make certain characters game-breakingly powerful.

Nobody should think less of you if you keep it simple

I hate the phrase "Keep it simple, stupid." Okay, really, I just hate the word "stupid." Having worked in UX alongside front-end, there's nothing stupid about simplicity. I find it much easier to over-engineer a solution than to make something shorter and with elegant purpose.

So if your solutions are simple? Great. You're doing the Lord's work, as my mother would have said.