A Programmer, Refactored: Recent Episodes
David R Tisdale, II
A podcast covering all manner of topics related to programmers, software developers, data developers, and other IT folks. Topics range from high-level career observations to more concrete technical discussions. The aim is for us to cover those things we wish someone would have pointed out to us years ago!
Have you ever worked in a blame-focused culture? It's a toxic culture, to say the least. Searching for blame after a bug has shipped accomplishes little and promotes bad politics. A listener emailed me an article from Code As A Craft that talked about Blameless Postmortems. It's a great concept, and it accurately describes some of the better cultures I've worked in, though it has its downsides. In this episode, I deep dive into the various concepts.
Have you ever had to work with senior technical professional who didn't have a background as a developer? It can be a tricky relationship. In this show, I respond to a listener's email who'd recently been assigned to work with a solutions architect that didn't have a developer background.
Have you ever worked at a shop where you loved the coding aspect, but hated the culture? Maybe they were too concerned with ship dates, or overly preoccupied with architecture, or spent too much time chasing frameworks. When we find ourselves in these predicaments, we often strive to change those parts we don't like, typically with poor results. In this episode, I dig into that phenomenon.
The user's place in the software development has changed a lot in the last ten years. Way back when, the user was a faceless entity that we tended to avoid. Today, thanks in no small part to the Agile movement, users and user representatives are often key stakeholders from the beginning of the SLDC. In this episode, I dig into how I think the user fits into today's software development process.
Reputation. As programmers, we tend to hang most of our reputation on our coding abilities, if we even think about our reputations at all. As very technical people, sometimes we fall into the trap of thinking that reputation is for managers and other political game players. The truth is, however, that reputation is highly important, and ignoring that can have horrible consequences. In this episode, I give a cautionary tale of a programmer who didn't heed that lesson.
Gatekeepers, those IT professionals who become so possessive of their systems that they become more of a hindrance than anything else. In this episode, I talk about gatekeepers in the context of software development and how they lead to shadow IT efforts.
The ability to self-manage is one of those things that separates an average programmer from a senior developer, in my opinion. In this episode, I talk about the importance of being able to manage your own time and work and strategies for doing so.
Software development is only partially a technical skill. As your career progresses, your people skills become as important. This is true even if you're never put into a leadership role of any kind. In this episode, I cover three tools I've used to help with my people skills game: Non-confrontational language, tactical empathy, and open-ended statements.
Last week I talked about how I realized I no longer want to write code professionally. In this week's episode, I go into how I arrived at this point in my career and how tech turnover pushed me into thinking beyond just implementation.
The other day while sitting at my desk, I had a sudden realization: I don't want to write code professionally anymore. I still enjoy it as an intellectual challenge, but professionally I'm in a different place. In this episode, I dig into the topic and go over some honest truths I've realized recently.
A few episodes ago, I talked about the importance of communication skills for programmers. In this episode, I wanted to provide a real world follow up to a story I told in that episode in order to demonstrate how sideways things can go when we as software developers don't communicate well.
If you write software in the modern world, chances are that you rely on at least one or two external libraries. Depending on your specific style and type of programmer, you might rely on quite a few. In this episode, I talk about how so much of the industry is shifting to using libraries for things we used to write by hand, and the effects that shift is having.
When I first began my career as a programmer, the world of software development seemed like this endless realm of possibilities. Today, I feel like I'm in some sort of no-mans-land. I don't fit in with the under-30 crowd nor do I want to go into management.
In this context, I've found myself asking, "Knowing what I know now, would I do this all over again?" In this episode, I explore that topic.
Have you ever wondered why it seems certain people in your organization have more success than you do, though you consider your work superior? In this episode, I talk about that very topic and how you can reframe the situation to better understand your organization's choices.
Communication in software development can be tricky. A miscommunication or misunderstanding can lead to hours or even days of wasted work. In this episode, I talk about my struggles with communication with users, managers, and other programmers, and hopefully lend some guidance for other programmers.
Career motivation for programmers can be difficult to maintain over the short-term, much less over a decades-long career. In this episode, I talk about the struggles I've had with career motivation, how what motivates me has changed for me over the years, and ways to keep up your motivation over time.
Every project has those aspects we'd rather avoid. Maybe it's front-end work, maybe it's database design, maybe it's writing tests. We avoid these things for reasons that are in my experience some version of "it's not fun". In this episode, I talk about why you should confront these aspects and improve your skills in those areas.
Our industry is one that has some interesting ideas about remote work and working from home. Few careers outside of software development get the opportunities for it that we do. I've done a fair bit of it myself, and in this episode, I talk about working from home and remote work.
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.
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.
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.
"Office politics" brings to mind images of nasty people backstabbing each other to jockey for position at the office. These days people prefer the phrase "soft skills". Whatever phrase you use, the truth is that maintaining good relationships with key people can help programmers and their projects really succeed. In this episode I go over some of those relationships that I think are really helpful for software developers.
Guys, I have had a tough couple of weeks and frankly have not been able to nail down a single topic I've wanted to cover. For today's show I'm going to key off of that and talk about a few things:
- Programmers who want the prestige of being a lead developer but not the responsibility
- Should programmers understand office politics?
- The dangers of ignoring the past
- The idea of "controlling one's emotions"
"Resume driven development" is a humorous and often derisive term for a certain style of programming and programmer. It's a tempting trap to fall into, but in this episode I go into my experiences with these types of developers and their projects and why you should avoid the temptation of becoming one.
Junior developers. We've all been one, and some of us still are. In this episode, I talk about some of my experiences as and thoughts on junior developers, which ones make for good hires, and I also try to offer encouragement to any junior devs out there who feel down and out.
In many shops, you often have someone, typically a manager, who's in charge of what and programmers who are in charge of the how. Is this a natural division of the work we do? In this episode, I explore why I think the what and how aren't truly separable.
We've all heard the term "goldplating" in software development, but what exactly is it? Who generates it, and why should it be avoided? In this episode, I dig into both stakeholder and developer driven goldplating, why it's bad, and how to mitigate its effects.
The Agile revolution was supposed to bring us new abilities to adapt to change in software projects. In many cases, Agile has delivered on that promise, but in many other cases, it can be just as inflexible as Waterfall. In this episode, I examine one such scenario and give some advice for programmers who find themselves in it.
We've all had to work with difficult programmers, but every once in a while we come across someone who's so onerous that they negatively impact the entire shop. Unfortunately, sometimes these people are also highly skilled in some key area of your organization. Are such people worth dealing with their toxic personalities? In this episode, I answer that question and offer insight from my own experiences with such developers.
Have you ever had to fix a bug in code that you didn't write? Most programmers have. A common thing I hear when this happens is for the developer to say, "That's not my code". In this episode, I talk about how unhelpful that phrase is and why I dislike it so much, as well as offering guidance on what to do if you find yourself consistently fixing someone else's bugs.
Taking pride in the code we write is really important. The best programmers treat it like a craft. But how much pride is too much pride? What happens when we find ourselves unwilling to admit when we're wrong? In this episode, we explore these concepts and end with takeaways for dealing with our own emotions and other defensive developers.
Some developers get to work on new projects, others of us provide maintenance on existing applications. Why do organizations separate the work like this? What are the effects of doing so? In this episode I dig into why some organizations separate greenfield from brownfield development and offer my perspective on that approach.
As software developers, our job is to deliver software that is appropriate for our user base so that they may solve some sort of problem. This is something I think we struggle with as an industry. In this episode, I dig into the topic of understanding your user base and then offer several takeaways to help you deliver better solutions to them.
We often encounter the phrase "ship early, ship often". What does it mean? Where does it fit into software dev and Agile specifically? In this episode, I examine the phrase and try to dig out some conclusions about when and where "ship early, ship often" really applies.
So many tech talking heads will advise someone in a tricky situation to "find a better job", but what if that's not possible? In this episode, I dig into the options programmers have when they can't or don't want to leave their current jobs.
The vast majority of software projects have deadlines. Sometimes these deadlines are realistic, other times they're not. In this episode, I dig into ways of effectively using what time you have to ship the best code possible, whether that deadline is far away or right around the corner.
Your organization has a specific culture. So does the department in which you work. Even your project team has a specific culture. Who drives these levels of culture? How can it be changed, or should it? In this episode, I dig into the topic and offer thoughts on how to understand, navigate, affect change, and use that culture to enhance your project, career, and overall job satisfaction.
Most software development projects these days divide tasks between the technical people and business people. Technical people include programmers, QA analysts, data professionals, and the like. Business people typically refers to project managers, product owners, and business analysts. For some projects, this dynamic clicks really well, but for others, it can become hostile. In this episode, I dig into some of the pitfalls of this relationship, how to repair and avoid broken dynamics, and why it's so important to keep this dynamic healthy.
Hopefully, our projects reach their v1 ship dates. Those last few months can be exciting and nerve-wracking. Many times, development teams will want to spend some of that period doing code cleanup, but what if v1 scope hasn't yet been completed? In the argument of MVP scope vs technical debt, who wins? I dig into that topic and give some advice on how to defuse the situation and hopefully avoid it altogether in the future.
Last week we dug into the non-technical reasons that cause projects to fail. As promised, this week I turn our attention to the various things that developers do that can cause projects to fail. I also spend a little time talking about the different meanings of failure in this industry. We finish up with takeaways for developers that will help them avoid this situation.
Software projects fail all of the time. When they do, we as developers can take it very personally. I think it's important for us to reflect on how we contributed to those failures, but I think it's equally important for us to understand some of the non-technical reasons that projects fail. In this episode, I explore some of those non-technical circumstances.
Lately, I've been seeing a lot of chatter regarding generalists vs specialists in the field of software development. It's an interesting and somewhat controversial topic. In this episode I dig into my take on it, the history behind the question as I've seen it, and my general thoughts and takeaways.
From a young age, we're told that the key to a fulfilling career is to find something we're passionate about and figure out how to make money at it. Our society places a great level of importance on having a satisfying career. I think this hits programmers harder than many because we truly tend to love what we do. Are those expectations about our careers realistic? Should we always be motivated and happy with our jobs? In this episode, I deep dive into some heavy issues to examine those topics.
Is your organization considering adopting Scrum? Have you yourself wondered what all the buzz is about? Are you a software developer or product owner that's found yourself struggling with it? In this episode I dig into my experiences and opinions on Scrum as a flavor of Agile.
I'm an enterprise developer, and so much of my time is spent pondering architectural issues on these humongous applications that we write. Lately, though, I've realized that I've fallen into the trap of Big Design Up Front. In this episode I share my thoughts on a recent personal project where BDUF completely hampered my ability to write any actual code.
Boy, do managers hate refactors. I've seen managers become livid just at the mention of the word. Why is that? Is their anger justified? In this episode I do a deep dive into refactoring to shed some light on the subject.
In episode 5, I talked about some of the shortcomings I'd found while working on a purely test driven development project. In this episode I outline some of the changes our team made for a more approachable TDD that fit better with our culture. I end the show with some overall thoughts on our process and its benefits and drawbacks.
Test Driven Development, or TDD. It's a buzzword we hear thrown around a lot in this industry. These days it's considered a de facto "best practice". Is it? What are its pluses and minuses? In this episode I shed some light on those questions by diving into my own experiences with it on an enterprise level project.
Do job titles matter for software developers? What's the career progression for a developer that doesn't want to go into management, anyway? In this show I attempt to answer those questions while also giving some commentary on what I think is a sad state of affairs for software developer careers. I end the show with some thoughts on what I'd like to see going forward!
We like to think that we're rewarded based on our abilities. I think this is especially true in STEM fields where we solve very complex, technical problems every day. I think many people regardless of field expect to be rewarded based on their ability and proficiency. Is that the case? Do we work in a meritocracy? This show digs into that question, tries to answer it, and finishes with some advice to help you navigate through the realities in our field.
I've heard many times throughout my career that "the user doesn't care what the code looks like, as long as it works". I've most often heard this phrase when a manager or some other stakeholder wanted me to release code before I thought it was ready. Today I'd like to examine that phrase and see if there's any truth to it.
We've all heard the term "technical debt". What exactly is it? How does it affect our projects? Can it be avoided? In this episode of A Programmer Refactored, I take a look at the phrase, dissect it a bit, then ultimately try to determine if its of any real use.