|
|
|
|
|
Yesterday, I got a calendar notification about my upcoming holidays. Two more weeks, then I'll relax in Spain for a week. Can't wait! What are your plans for the summer?
|
|
|
|
|
Mentor Monologue
|
A question I get asked regularly in my coaching conversations and on my Office Hour live streams (which I do every Friday at 1pm on Twitch) is "How many programming languages do I need to know to be a good software engineer?"
|
There is no canonical answer to this question. Don't feel bad if you know someone who has experience with more programming languages than you do. More isn't necessarily better!
|
I can count more than a dozen languages that I learned and wrote at least a few lines of code in. That's over the span of four decades now. I wrote my first BASIC program in 1984. 👴 But I also haven't touched most of these languages in decades, too. For example, in college, I learned Prolog and Ada. Did I ever use them to write any substantial application? No. Do I still use them today? Also no. (That being said, I'd love to revisit Ada now that I can see its strengths much better than as a distracted student 20 years ago.)
|
As a software engineer, you don't get paid in proportion to how many programming languages you know. 💶 You're paid for solving business problems via software.
|
To meet this requirement, you only need to be proficient in one programming language. It's the one with which you can solve problems for your current or for you future company. Most of the time, the business will tell you which one that is. In rare cases, you get to decide yourself. In both cases, you need to master only this one language. So go and pick a programming language that is in enough use to give you a decent amount of hiring opportunities. COBOL, for example, might still be in use after more than 60 years, but at so few organizations that I wouldn't consider learning it a great career choice. 😁
|
Put in the time and effort to reach mastery of your programming language. We're talking about years of experience here. That way, you'll build the vertical stem of the T.
|
|
Where did that T come from all of a sudden? Well, in my career advice, I use to promote the ideal of the "T-shaped engineer". The T with its vertical stem and horizontal bar visualizes the distribution of know-how I advise you to strive for: Master one area (in this context one programming language) in depth, reach senior developer level in it, become an expert.
|
|
|
Now, let's take a look the horizontal bar of our T. While you're deepening your skills in your bread-and-butter language, divert a little of your time and attention to other languages as well. The goal is to build up a broad, albeit shallow, spectrum of knowledge in alternative approaches. Why? Because every language has its strengths and weaknesses, each one favours certain use cases and practical applications that differ more or less from the others. Learning about one language's philosophy and being able to apply this insight in whatever other language will make you a much more well-rounded engineer. You can apply object-oriented design in a language that has no built-in OOP language features such as C. You can introduce Functional Programming strategies in a non-functional language like Ruby. 💡 A growing repertoire of patterns and approaches will allow you to solve business problems better, faster, more effectively. And that's what you're getting paid for.
|
|
In conclusion, you only need to master one programming language to be a good software engineer. To become a great one, gradually expand your horizon and learn other ones well enough to extract insight that improves your ability to solve the problems your job confronts you with day by day.
|
|
|
From the blog
|
I finally published the recording of the video interview that fellow streamer and cybersecurity engineer Brad did with me back in March. It was a fun conversation, and I hope you'll enjoy learning about my crippling keyboard addiction and how I was once fired while on holidays!
|
|
In The Server Room
|
|
|
Recommended reading
|
As an online teacher, I always recommend additional material to my students with which they can expand their horizon. Here's a list of reading tips I've curated for you.
|
|
“Host your own dependencies, put a cache directly in front of your application, and make your application resilient to missing resources.” Timeless advice.
|
Insightful. I can relate to the thought of parenting twin babies as constant incident response.
|
A nice tutorial about building a multi-tenant Rails application without using a third-party gem like Apartment or acts_as_tenant.
|
If you're interested in distributed systems, this article will provide you with a lot of background information.
|
|
It's becoming more common to check shell scripts before we download and execute them, often by using the infamous curl-bash pipeline. This article makes it very clear that we need to apply the same diligence when we import database dumps.
|
|
|
Thanks for reading!
|
I hope you found my News from The Server Room enjoyable and helpful. If you have any feedback or questions, simply reply to this email!
|
|
Jochen, the Monospace Mentor
|
|
|
|
|