I can be a pretty honest and direct guy, and that has gotten me into hot water as a programmer on more than one occasion. In this episode I talk about my struggles with trying to be more diplomatic and the mixed feelings I have about it.
We're all leaders to some degree. Even if your job title doesn't have words like "manager", "architect", or "senior", you're still every week presented with opportunities to display good or bad leadership traits. These traits can have an especially outsize effect on junior developers. In this episode, I go over the importance of honing your leadership skills.
If you haven't encountered a programmer who's dogmatic about some aspect of their work, you will. Dealing with these software developers can be very trying. In this episode, I explore the topic and give some pointers on how to identify and deal with them.
About once a year I like to do a career self-assessment. In this episode, I talk about how I go about doing it, why I think they're important for programmers, and whether or not trying to plan out a career in such a fast-changing field even makes sense.
Software development is a fast-changing environment. New tech, platforms, libraries, and frameworks seem to come every week. How does being a senior developer fit into that? Is it possible to even be senior in such an environment? In this episode, I explore the idea as well as recap the "Things I Wish I Knew" series as a whole.
As a young programmer, I figured that my abilities as a developer would be the primary driver of my career trajectory. As the years have gone on, I've realized that notion was a bit naive. In this episode, I examine what I've seen drive career progression in this industry.
Up until a few years ago, I held this assumption that job titles carry at least some meaning and weight. As I've advanced in my career, I've found this to be a dubious assumption at best. In today's epsiode, we I talk about job titles for programmers and their meaning (or lack of) within the software development industry.
Programming is unique in that job postings can be...creative with the truth. This is, unfortunately, something we typically only learn after a few years in the industry. In this episode, I examine inaccurate job postings.
Being a programmer means that often people outside of other developers will have no idea what you do. Trying to explain your career to them will often lead to glazed over expressions. In this episode, I talk about some of the more humorous aspects of this, as well as some of the more serious.
I like to think that our industry is one such that each generation of programmers builds on the experience of the previous. In some cases, I think this is true, but more often I feel like we let ourselves get caught in the cycle of hype. In this episode, I dig into the topic of experience vs hype and which drives the other.
We like to think that users use our software because they've evaluated their options and found our software to be the best at enhancing their lives or jobs. However, in the enterprise or B2B environments, this is rarely the case. In this episode I explore the real reasons such users are using your software.
We talk about code quality a lot, and for good reason, but where does it fall in the list of things that really contribute to a project's success? Top 3? Top 5? If not there, why is it still so important? Today's show digs into that topic.
Blaming the last programmer. We've all done it. It's practically a time-honored tradition. I find it both fascinating and annoying. In this more lighthearted, I talk about blaming the coder before you and some of the insights about it.
Last week I talked about rollouts in general. Today we're going to talk about ways I've seen software rollouts go horribly wrong.
Whatever kind of developer you are, for most of us shipping code is our overall objective. At some point, all the theory about patterns and business rules and the debates about frameworks and tech give way to the realities of getting your code in front of the users. In this episode, I talk about those realities.
We like to think that people get what they deserve, that their good or bad karma will catch up to them. This is true even of logical thinkers like programmers. We like to think that developers who work hard and ship good software will be rewarded and that good leaders will be promoted into management. In this episode, I talk about these ideas and whether or not they're realistic.
I expect a lot of myself professionally. That comes largely from my upbringing and my early 20s, and it sometimes causes me to be really hard on myself. I also tend to carry those expectations over to others, and that can cause me to struggle when I feel others haven't met those expectations. In this bonus episode, I talk about those expectations and whether or not they're realistic.
Incorporating trendy new tech into our projects can be a big temptation. Last week I talked about some of the dangers of doing just that, this week I want to talk about the criteria I think your project should meet if you are going to pull in some of those things.
Programming, and web dev especially, can be prone to fads. In some respects, they drive innovation, but from another point of view, I think the constant reinvention stifles our ability to build solutions that can stand the test of time. In this episode, I dig into the dangers of fads and how I ended up burned out from web dev.
Last week we talked about the importance of building key relationships in the hopes of giving you, your developers, and your project an increased chance of success. What if those relationships go wrong, or already are? In this show I go over how to repair those relationships when possible and mitigate them when you can't.