Category: Self-Improvement

Finding the Benefits of Impostor Syndrome

I am a frequent listener to the podcast Software Engineering Daily. On a recent episode Facebook Engineering Culture, Kent Beck shared his experiences from his time at Facebook. It’s a great episode and I would highly encourage giving it a listen as there are a lot of really interesting nuggets of information. One subject I found really interesting was when Mr. Beck shared how he initially struggled when first joining Facebook and how he dealt with a common feeling in the software engineering world, Impostor syndrome.

We Are All Imposters

Kent Beck was an early advocate for Test-Driven Development and Extreme Programming. He has written a number of popular books on the subjects and has been an influential voice in the software engineering world at-large for several decades now. With such a reputation Mr. Beck is not someone you would think would have to worry about feeling like an impostor.

In 2011 Mr. Beck joined Facebook, with already decades in the industry, he had thought he had “seen it all”. When joining Facebook, new engineers would go through a multi-week “bootcamp” as a way to introduce them to Facebook’s engineering culture. It was during bootcamp Mr. Beck realized he had in fact not seen it all. Facebook’s engineering culture deviated significantly from what he’d thought would be successful; few automated tests were being written, when he decided to hold a class on TDD, no one attended, and he felt he was one of the worst C++ programmers at Facebook, which was reflected in a bad review he got.

Mr. Beck had built his career and reputation on processes that put emphasis on writing automated tests, yet Facebook was finding success in not following these practices. When Mr. Beck tried to uses TDD practices at Facebook, he struggled. Upon realizing he was not performing well at Facebook, he get a feeling familiar to so many other developers, he was an imposter.

Programming Isn’t Just About Slinging Code

Slowly the software engineering world has been moving away from exclusively measuring the worth of a developer in how well they can “sling code”. A funny example of this was when tech twitter was ablaze for few weeks during the summer of 2019 with “10x engineer” memes. While it’s good that there is a greater appreciation that skills outside technical ones are necessary to be a successful developer, often when we experience imposter syndrome it’s because of our concerns related to our technical know how.

This is where Mr. Beck was finding himself back at Facebook. Despite his decades of experience and accomplishments, Mr. Beck realized that he wasn’t going to make it at Facebook just by “slinging code”. So Mr. Beck did some self-evaluation found that he would be of better service by helping to coaching up other engineers:

It was clear that just trying to sling code was not my differential advantage there. I started coaching. I had done a fair amount of one-on-one coaching with engineers before. There were no coaches at Facebook. I could see that there were engineers with tons of unrealized potential.

Because Facebook was solving unprecedented problems, there was no way they could hire somebody to solve them. They had a big bunch of the technical horsepower had to be generated in-house. I started this coaching program called good to great and began working with engineers one on one. Ended up coaching maybe a 150 or 200 engineers.

Personally, the program matched up other senior engineers with junior engineers who got more coaching. My students were demonstrably faster at getting promotions. They were twice as likely to get promoted in the year following coaching than their peers who didn’t get coached, all other things being as much equal as possible.

When we are experiencing imposter syndrome, it is important to remember that even if we lack the technical know how or skill in one area, there are other skills we have that can be of benefit to our organizations. For Mr. Beck it was his skill as a coach that helped him be successful, for you it might be skills and ability in some other area. If you are dealing with feeling like an imposter, take a moment for self-evaluation to see what other skills you could utilize to be successful.

Improvise, Adapt, Overcome

While Kent Beck was improvising by utilizing his coaching skills, a key decision he made was to re-evaluate his approach to programming. As mentioned above, Mr. Beck helped popularize Test-Driven Development. He wasn’t someone who casually wrote a unit test here or there, he literally wrote books on automated testing. However Mr. Beck wasn’t going to be successful by following these methodologies at Facebook, he was going to have to adapt:

I deliberately chose to forget everything I knew about software engineering. I just said, “I’m going to try and be a programmer and I’m going to watch what people do. I’m just going to copy what they do. If somebody says this is too diff since that one, it will be too diffs. If somebody says you need tests for this, I’ll write tests. If they say you don’t need tests for that. Why are you writing tests? Then I won’t write tests, even if I think that’s my – that’s the natural thing to do.

When dealing with the feeling of being an imposter, Mr. Beck didn’t become overwhelmed by it, nor did he suppress it. Instead he embraced it and then overcame it by using it as an opportunity to grow as a software engineer.

Conclusion

As someone who has also at times felt like I’m an impostor, it is good to know that even someone as accomplished as Kent Beck has experienced that same feeling as well. What is important though when encountering that feeling you are an impostor is to remember you have other skills that you can use to be successful and to take the opportunity to learn new ways of being successful so you can grow as an engineer and person.

Quotes taken from show transcript.

Three Books Every Developer Should Read

A lot goes into growing your career and knowledge as a developer. There are many ways to learn; the most common would be experience from the day-to-day work of being a developer, a bit more self directed would be; building small proof of concepts with a cool new tool or framework, reading blog articles, watching videos, or listening to podcasts, all are great ways to learn, and each provide their own unique benefits. However these forms typically are more concerned with answering the what or how. Books are another popular form of learning and where they differ from the other forms is their focus on the why.

Books, by focusing on the why, help to explain the underlying principles and rationale behind a practice or pattern. It is one thing, for example, to know that it is a good practice to wrap all calls to an outside service in a circuit breaker. It’s another to understand the goals and benefits behind the practice. This deeper level of understanding can help a developer make the move from junior to senior in more than title.

In this article I’m going to offer recommendations on three books that have read that have really helped me in my career. These books cover a wide range of subject areas; system/application design, reliability, and delivery. While the code examples in the book may be written in a language different from what you are familiar with, the principles are technology agnostic. So rather you are a; C#, Java, JavaScript, frontend or backend developer all these books should still be relevant and beneficial.

Domain Driven Design

Image result for domain driven design

Author: Eric Evans, Amazon

If you have wondered where the term “Domain Driven Design” came from, it is from this 2003 book. The concept of Domain Driven Design (DDD) has been talked about, blogged about, and tweeted about, a lot since its initial release. The quality of the commentary can vary, but it’s difficult to properly condense down a 560 page book into a 1000-2000 word blog article or hour long talk.

Despite it being written all the way back in 2003, its lessons are still as relevant as ever. A concept particularly important for today would be bounded contexts. If you are considering switching to a microservice-style architecture, finding the edges of a context is critical or else you might end up changing very cheap method calls inside a monolith application with very expensive http calls between services.

Favorite Lesson in the Book

Ubiquitous Language –  Early in my career I would frequently see code that would have very generic names Processor, a, validate, and so on. Figuring out what the code was doing or how it related to business needs was difficult. Ubiquitous Language describes writing code using the same nouns and verbs that your team uses to describe business concepts. So instead of Processor you might have CuustomAccountProcessor, appointment instead of a, and validateMailingAddress.  While the concept of “self-documenting code” is a myth, writing code in this way helps to lower the learning curve for new developers, or even for yourself months later when returning to a project or module.

Release It!

Image result for Release IT

Author: Michael Nygard, Amazon

Michael Nygard’s 2007 book covers how to design applications and systems to be fault tolerant and provide a good experience to clients when problems inevitably occur. The book covers several areas that can affect the performance of an application and/or system. The book is written in an anti-pattern/good pattern format, first covering a widely followed anti-pattern, the problems from following that anti-pattern, and then a good pattern that addresses the same need, but creates an application or system that is more stable, responsive, and able to recover from outages.

The image above is from the first edition, which as mentioned was released in 2007. This is the edition of Release It! I have read, but a second edition was released early last year. The Amazon link above is to the edition of the book which is the edition I would recommend reading. The reviews of the second edition suggest it is just as well written as the first edition.

Favorite Lesson in the Book

Limiting Cascading Failures – No matter the careful planning, amount of resources available, or good design practices followed, failures will happen. Finding out the cause of a failure is something to worry about later, what is important, in the moment, is returning to normal state as quickly as possible. The steps to getting to normal state will vary, but it will always be faster and easier if you design systems to limit the scope of a failure. If a database goes down, it will always be harder to return to normal state, if the application(s) that depend upon that database also crash and/or need to be restarted.

Several organizations I have been with didn’t see as much of an issue if a downstream service also crashed/needed to be restarted, the thought being they wouldn’t be usable anyways. This always complicated the process of returning to a normal state and additionally impacted deployments as there was a deployment order requirement. Designing systems to limit cascading failures makes recovery from failures faster and can also have the added benefit of making deployments easier as well.

Continuous Delivery

Image result for continuous delivery book

Authors: Jez Humble and David Farley, Amazon

On the subjects of deployments we have, Continuous Delivery. Not that I am playing favorites with my book recommendations, but Continuous Delivery has had the most profound impact on my career and how I view software development. The lessons in Continuous Delivery really resonated with me as it often covered the pain points I was often experiencing as a developer at the time and offered much more practical and sensible solutions that addressed them.

Continuous Delivery is one of the major reasons for why I got really interested in automated testing, as automated testing is the foundation on which continuous delivery (the practice) is built. Generally speaking my opinion is that if more organizations got continuous delivery right, it would address a lot of the other problems they are frequently dealing with.

Favorite Lesson in the Book:

Auditability and reproducibility – The major theme in Continuous Delivery is automating the delivery pipeline to production. When the subject of automation is discussed, often its benefits are described as being increased speed and reduced costs from replacing slow and expensive manual labor with processes executed by machine (script). These are certainly significant benefits, but, while subtle, the biggest benefits of automation in my opinion are its quality of being auditable and reproducible, which are also covered in Continuous Delivery.

Automated processes by their very nature are auditable and reproducible. Want to know what an automated test is doing? Look at the code for the automated test. Want to see what happened during a deployment? Look at the logging from the system the executed the deployment script. Automated tests can be repeated, deployment scripts reran to narrow in on and investigate a potential issue. Not to overhype automation too much, as it’s not a panacea, but its benefits over manual processes are difficult to overstate.

Conclusion

There are many great books on software development available. This is only a small selection that I have found particularly helpful. I have found myself frequently thinking back to lessons learned from these books and referencing these books in presentations and blog articles. Taking the time to read some books is really important for all developers. Rather it’s the books listed in this article or others, I hope you set aside some time to pop open a book. While benefits may not always be immediate and often require a relatively high investment in time, books can provide longterm returns in ways other types of learning may not always be able.