Staff backend engineer 👨🏻💻 Write about purposeful dev careers ✍️ Passionate about #climate 🌍
Articles by Bennett Garner
Junior developers, you can figure it out on your own!
There’s a common problem I often encounter. It’s prevalent among more junior developers, but it can also affect developers with many years of experience. Put simply: they want to be told how to solve the problem, rather than figuring it out themselves. The desire to be told what to do can take many forms. Lots of questions, long threads on Slack, or multiple requests to pair. It’s scary & vulnerable to put yourself out there.
What’s a Sybil Attack & How Do Blockchains Prevent Them?
A Sybil attack is an attempt to control a peer network by creating multiple fake identities. To outside observers, these fake identities appear to be unique users. However, behind the scenes, a single entity controls many identities at once. As a result, that entity can influence the network through additional voting power in a democratic network, or echo chamber messaging in a social network.
Coping with the Task Saturation of Software Development
I love airplanes & all things aviation. Recently, I was reading about the top causes of accidents for general aviation pilots. One of the main factors in accidents is the pilot’s task saturation. Task saturation refers to having too many things to do at once. You get overwhelmed & make poor judgments. As software developers, we’re not flying airplanes thousands of feet above the ground.
One specific type of imposter syndrome limits even senior developers
One particular flavor of imposter syndrome is surprisingly common, even among the most senior developers. Imposter syndrome is the nagging loop in your head that tells you you’re not good enough to be coding for a living. Or, that you don’t deserve that promotion. There’s one specific version of imposter syndrome that I see all time. I call it “Not the best”-itis. Comparing yourself to your peers in an endless loop.
What Is a DEX? Decentralized Exchanges, Explained
A decentralized exchange, or DEX, is exactly what it sounds like– a cryptocurrency exchange that is completely decentralized. Here are three reasons DEXes are worth paying attention to: Decentralized exchanges are peer-to-peer hubs where users can directly trade crypto without intermediaries like centralized exchanges or other financial gatekeepers.
Coding projects & building from scratch
Yesterday, I wrote about how there's no such thing as pure coding. Everything you build will rely on libraries in some way, and much of the work of a software developer is getting libraries to do the thing you want. So, when you're building a personal project, don't be afraid to use a library. Certainly don't feel inferior that it's not Pure Coding, whatever that means. However, a list member wrote me with one important caveat: understanding how things really work under the hood.
Using libraries vs "pure" coding
The only way I could do one of those in an afternoon would be if I could find a library or framework to do the heavy lifting. That is not coding, it is using. I wrote a list of potential coding projects that you could do in an afternoon, and someone left me this comment: That's a curious response to me. This person thinks that using a library is not Real Coding™.
Quick projects to do in a weekend
Start, implement, and finish. So often, I see developers get stuck working on a side project for weeks or months at a time. You spin your wheels and waste time when you struggle with the details of a big sprawling project. Today, I want to share a few project ideas that you can do in a weekend, quickly get the value, and then decide to throw it away or keep building on the idea. The important lesson: Quick wins build momentum. Don't let a big project sap your energy.
When you shouldn't do the easy thing
Yesterday, I wrote a story about a developer who quickly implements a "nice to have" feature. But I didn't say whether the developer was RIGHT to work on that project. Whether the easy thing is the right thing is always about context & tradeoffs. Will the easy thing take two minutes or two days? What else is the team working on? Is the easy thing a distraction? Is this developer just "snacking" - finding easy changes to do instead of tackling a difficult, higher value change?
Coding for a living is a treadmill
Often, as developers we find ourselves pushing for the next deadline. But when it comes - succeed or fail - there's always more work to do next week. The truth is that coding for a living (and nearly any other job for that matter) is a treadmill. It never ends. Your software is never done. The company doesn't magically run out of problems to solve. This is an infinite game. Sprinting toward the next deadline will only tire yourself out. So, what are your options?
Doing a PUBLIC RETRO of our own podcast | Meaning in Code | Episode 12
This week on the Meaning in Code podcast, we take a look back on season 1. We performed a classic retrospective to see what we learned, our wins, and where we want to improve.
"Be more careful" isn't good enough after an incident
Yesterday, I posted a comic where the character's main takeaway after a production incident was to "be more careful next time." The final pane of the comic said, "that implies you were careless this time..." Some folks on my email list were quick to point out that having an incident doesn't imply carelessness. That's totally fair & correct! As the author of the comic, I should've chosen a better punch line for the final pane. I actually struggled with this week's punch line.
Isolate your tools
Yesterday I wrote about being tool-agnostic within your given niche. As part of that post, I advocated isolating your tools & leaving as much logic as possible in vanilla code. For example, yesterday's article talked about isolating your choice of web framework from the business logic that actually does the work.
One valuable coding productivity tip: Avoid snacking
I'm not talking about food. This is an article about how you pick what to work on. Find something that has a high impact if you want to grow your career. You can think about the difficulty of a coding task along an axis - low effort to high effort. Similarly, you can think of the impact or value of that coding task along an axis - low impact to high impact.
When you don't want to play the coding game
Yesterday, I wrote about how software development is an infinite game. There's no way to "win" at coding. The objective is to keep playing. But that assumes that you want to play the coding game. You don't have to want to play this infinite game. There's nothing wrong with leaving. But you'll inevitably be faced with another infinite game to play. It turns out that careers, business, and our entire life paths can be thought of as infinite games. Do you want to play the infinite game of coding?
Infinite mindset in programming
There is no way to "win" at coding. The point of the game is to keep playing. In game theory, there are finite and infinite games. Chess is an example of a finite game. There are hard rules, boundaries to your possible moves, and a clear end where one person wins and the other loses. By contrast, infinite games are unbounded. They can have many players, no hard limits on moves, and no definitive end. Some developers (and entire businesses) treat software like a finite game that you can win.
How to raise your rates as a freelance developer
This week, I received a reader question (shortened & anonymized here)... I'm a freelance WordPress developer, looking to improve my rates & the quality of services I offer. I always read that providing value isn't just about delivering a website. It's about "solutions" that reduce costs or increase revenue. However, I doubt what kind of "solutions" I can offer. The question is a good one & one that freelancers struggle with constantly. I don't have a magic answer, but I do have some ideas.
Work in progress is slowing you down
Having multiple projects in-flight is a sure fire way to slow things down. It can be tempting when working as a software developer to spread yourself wide across many different initiatives. You make tiny progress on each one, constantly switching back and forth. But it seems you never actually finish anything! Or at least it takes a long time! In the same way, entire teams can be bogged down by having too much work in progress.
Confronting the pressure to work nights & weekends | Meaning in Code | Episode 10
In this week's episode, we discuss team culture around work expectations, feeling like you need to work late, and what you can do about it. Talking points: - The difference between flexible work schedules and the expectation to be flexible - How to set your boundaries & maintain them with your team - The ways Lillie & Bennett have influenced team culture around working late - What are your options if working nights & weekends is the norm at your company?
Is a meaningful career possible in tech? | Meaning in Code | Episode 9
This week on the Meaning in Code podcast, we go deep! Is any of this worth talking about? Or, are is it foolish to look for purpose at work? Talking points: - Lillie's coworkers challenged the premise of a meaningful career. Isn't work what you do for money?
Do developers have shorter careers? | Meaning in Code | Episode 8
How do software engineering careers compare to those in other fields? Is your engineering career really likely to end more quickly than your peers? And for goodness sake, how can you squeeze making a full meal into the middle of your day?
How to advance in your software developer career | Meaning in Code | Episode 7
In this week's episode of the *Meaning in Code* podcast, we're talking about how to advance in your career. What habits, routines, and mindsets take you from newbie coder to value-creating engineer? Discussed in this episode: - Why your job is less about coding the more you grow in seniority - Overwhelm is normal! How do you decide what's most important?
Starting a new developer job? Here's what to do in the first 90 days. | Meaning in Code | Episode 6
Starting a new job can be intense as a software developer, but with a few key steps you can set yourself up for success.
The next CODING skill you should learn & how to choose | Meaning in Code | Episode 5
This week we talk about a recurring question for software developers... How do you decide what to learn next? Highlights from this episode: - Resources for how to discover things you don't know about - Why adjacency is one of the best heuristics for what to learn next - Shiny object syndrome & why to avoid it - How to stay up to date in your field without needing to learn every new thing that comes along Daily email list: https://bennettgarner.ck.page
Your dev career is more than just your job | Meaning in Code | Episode 4
August 22, 2023 by Bennett Garner, Lillie Schachter Your developer career can be more than the job you happen to have at any given time. How do you move your career forward meaningfully outside of the job you do each day? We talk about: - Is your job just the thing you do for money?
How to combat imposter syndrome (+ more Q&A topics) | Meaning in Code | Episode 3
August 17, 2023 by Bennett Garner, Lillie Schachter Lillie & Bennett are back with a Q&A episode where we tackle some difficult, big topics in software development. Covered in this episode: - Mindsets for combating impostor syndrome - Lillie's exact study plan for excelling in technical interviews - Strategies for overcoming coding roadblocks - What to do when team dynamics & culture are a challenge Get on the daily email list: https://bennettgarner.ck.page What is Meaning in Code?
How to succeed while coding remotely
Not too long ago, remote work was a dream. A work arrangement that only very few engineers could pull off. It's striking to internalize how new this way of working is. Obviously, the Covid pandemic flipped the work world upside down. Now, many jobs are remote. Tons of companies claim to be remote-first. But that doesn't mean the companies are good at it. Nor does it mean that you'll automatically be good at remote work. I'm an advocate for remote work.
Stop calling them "side" projects
Software developers love a good project. Building something new, either for fun, practice, or to show off skills for a portfolio. Most people call these "side projects." That seems unnecessarily diminutive to me. I prefer to just call them "projects" and not undermine their value. Sure, you may have a primary job and be building your projects in your free time. Perhaps they're loosely maintained or seldom receive new features.
How do you define your own meaning in your software career? | Meaning in Code | Episode 2
August 8, 2023 by Bennett Garner, Lillie Schachter This week we get practical with tips on how to make difficult decisions in your career as a software engineer.
Can a developer career have meaning & purpose? | Meaning in Code | Episode 1
August 1, 2023 by Bennett Garner, Lillie Schachter Bennett Garner is joined by Lillie Schachter for the first episode of a podcast about building a meaningful developer career. This week, we address the topic head on - what might make a career meaningful?
Starting a software consulting business
This week on the channel, I share my experience and insights on starting a consulting business. Covered in this video: How to find your niche Horizontal vs vertical specializations Product, service, or productized service How to acquire your first clients Scoping projects Pricing services based on value Starting a consulting business is really hard! It won't solve all your problems to work for yourself - in fact you'll probably have more problems.
The Economics of Software
Because the economics of software make code really valuable. And writing code is (sometimes) hard. Good developers invariably produce many times more value than they're paid. That's difficult to internalize, so let's look at an example. $20/month is a pretty common price for consumer subscription software out there. Get 1,000 people to pay for it and you have 1,000 x $20 = $20,000 in monthly recurring revenue (MRR). That's $240,000 in annual recurring revenue (ARR).
How I'm learning Golang without tutorials
If you want to learn to code (or a new language) for real, you have to stop doing tutorials. Tutorials are a trap. They're a crutch that keep you reliant on new instructions. But as a software developer, your job is to build new things, solving problems that haven't been encountered in the same way before. This month, out of curiosity, I finally started learning Go. I strongly believe that you get better as a developer when you learn a new language.
Don't say "hello." How to ask good questions about code
One of my coworkers shared a funny link this morning: https://www.nohello.com/ It's a pet peeve of mine as well - just saying "hello" in an asynchronous communication channel. In the age of Slack & Teams, I think we've gotten better about communication habits. More than ever, people are respectful of the channels they use to communicate & often don't beat around the bush.
3 Senses [#2]: See, feel, hear
Another edition in my new 3 Senses series! Thanks to everyone who gave their feedback on the last edition. It was fun to hear about other things fellow list members are into, besides coding: - - - I love sharing your responses with the rest of the list. It helps build community & see the humanity of this email list.
How to measure the value you create with your code
This week, I've been emailing with a developer who wants to get better at selling himself. A key challenge is sharing the value of his code with people who have no context. For nearly all of us developers, this is true. We work on highly-specific, technical problems. At the end of the day, it can be hard to explain what we did to someone outside your team. But to get better at selling yourself, you need to show the value you create. How?
Is refactoring worth it?
You might be wasting your time. This week on the YouTube channel, I discuss the dilemma of whether or not to refactor code that may not have the best design. There are always trade-offs involved in leaving messy code versus investing time in making it better designed. It's not straightforward whether you should undertake a refactor. Understanding the scope of the refactor is also critical. Your changes can have a big impact on future developers and the overall system.
Practical tips on how to sell yourself as a developer
Developers create outsized value for their companies. When it comes time to find a new job or ask for a promotion, many developers find it difficult to quantify that value. It can be difficult to share your value - to sell yourself - without feeling sheepish, greedy, or over-the-top. The result is many developers work on teams where they're undervalued. Or, they encounter hurdles in the hiring process from not being able to get the team on board for their skills/abilities.
"Sorry, I can't review your code"
Running an email list for developers, I receive a lot of requests to review sample code, developer portfolios, and business ideas. Unfortunately, I don't have the time (nor the desire) to review that much code! Since I can't give everyone a review, I have a blanket policy against reviewing code, project ideas, or business proposals. As you can imagine, with over 2,000 developers on my daily list it'd be impossible to help everyone.
Updating legacy software
This week at Satiresoft...
How to improve as a software developer
If you've lifted weights, you know that growth happens at the limits. Start with a light weight, perfect your form. Gradually add weight, session after session. Find a weight that exhausts you. Lift that weight to failure. The next time you lift, you'll be a little stronger. Keep adding weight & keep lifting to exhaustion. When you lift weights, you are constantly working on finding the limit. Push yourself to get to the limit & that's where you get stronger.
I need a new name for my comic
I've been writing my comic, Alpha Software, for nearly a year now. Apparently, there's a real company called Alpha Software. They're fans of the comic, but they don't love the competition for the name. I recently received a message from the VP of Marketing at Alpha Software making it clear that they hold the trademark and would like me to call my comic something else. In a sign of good faith & out of an abundance of legal caution, I've taken down the historical posts of the comic.
Pick beliefs that are useful, even if not true
Derek Sivers is an odd dude. He lives globally. Renounced his US citizenship. Is a millionaire from selling his company, but lives a sparse life. Donates all the profits from his books to charity. One of his ideas has wormed its way inside my head: I've recently adopted a useful belief that has changed my perspective as a software engineer. It may not be true. Maybe that last person did a rush job or didn't care. But it doesn't matter. The belief is still useful.
Developers, you should consider becoming a manager
Keep growing as an individual contributor (IC), working on larger projects with more stakeholders & more business accountability Or, make a move into management, leading teams of developers to deliver software at scale At some point in your developer career you'll face a choice: Many people will portray this choice as all-or-nothing. You're either an IC or a manager, and once you choose it'll be impossible to go back. That's not true.
Show More
loading
Actions
Is this you?
As a journalist, you can create a free Muck Rack account to customize your profile, list your contact preferences, and upload a portfolio of your best work.Get in touch with Bennett
Contact Bennett, search articles and posts on X, monitor coverage, and track replies from one place.
Learn more about Muck Rack