Letter to my 21 years self
Dear 21 year old Twerp,
Life has been good to you. It’s been predictable and quaint. You are starting a professional career in software engineering. This will end up being your life for the next few decades. Don’t worry, you’ll enjoy most of it. I just wanted to give you a few tips to help you make sense of the world around you and make the journey easier. This may sound like unsolicited advice that you get from your father, but it’s useful. On an unrelated note, listen to your father .
Tip #1: Be an engineer, not a coder
An engineer solves problems (and I know you love a good puzzle). Solving problems is what gets people appreciated, paid and promoted. You aren’t paid to write code, you’re paid to solve a problem. Make that the centre piece of your brand. Be a problem-solver. If you don’t know a solution, google it, talk to people, propose alternative solutions, get said alternative solutions shot down. This is the only way to build a successful career. Surprisingly, you’ll even get hired for sheer tenacity. Apparently, people value this.
Tip #2: Value people more than code
Companies, projects, teams, communities are all made up of people and not code. It’s easier to refactor code than it is to refactor people (if that’s even possible). Value people, try to understand them, question them and above all respect them. You’ll hire & be hired, you’ll fire & be fired. Remember, it’s people who do the hiring and firing. Technology, frameworks, languages are all ephemeral. Your journey will be defined by people, not technology.
Tip #3: Don’t be afraid of code
I know this sounds silly (considering that you are a software engineer). You have a tendency to not read code that you (or your team) aren’t actively working on. I’m talking about the 3rd party software that you use; frameworks, libraries, shell commands etc. Don’t be afraid of their source code. Their authors are much better than you and have much to teach. Read code more than you read documentation. It’ll help you understand the idiomatic ways to do things, teach new language features and help you bring the framework into submission much faster.
Tip #4: RTFM!
Ironically, learn by reading the documentation. It’s a very good indicator indicator of any project (especially OSS). It shows you the thought process of the engineers who worked on it. It tells you if they care about the user (you). It shows if the code is being actively maintained. You’ve fried micro-controllers worth hundreds of dollars in the past because you didn’t RTFM. Don’t do this with software. You actually impact people’s lives.
Tip #5: Beware of purists
Purists by definition believe in a single world-view. Beware of them! Most are snake-oil salesmen selling you their ideology. Read about Uncle Bob, Clean Code, small functions. Read them all because they make a good point. But before you implement their ideology, Think. The world is not made of black & white characters. Instead, it’s all about grey characters, the in-betweeners, the middle path. There’s no “Way of the Right” or “Way of the wrong”. There’s just “Way of the it-depends”. Enterprise software is hard to build because it changes rapidly. You won’t be working in a pure environment such as an operating systems, language design etc. You’ll be working on features because that’s what the sales person managed to sell. A feature that sells the software is the only feature that counts.
Tip #6: Don’t be shy
Don’t be shy to express your thoughts in public. Just because something has been said in the past, that doesn’t mean you shouldn’t say it anymore. Your perspective and your life’s biases will make your POV unique. At best, people will listen to you and forget about you. At worst, they won’t listen to you. There’s no downside. So go write those posts, give those talks and attend those meetups. Look like an idiot every once in a while. You might just end up making good friends in the process.
If you heed these words,
Yours is the Earth and everything that’s in it,
And—which is more—you’ll be a Man, my son!