Stories about Software


Conference Speaking Isn’t Good for Your Career Until You Make it Good

I like watching developer talks, live and recorded.  For my money (or free, depending on the venue), it doesn’t get any better than listening to Bob Martin work his way into a talk on software design by talking first about astronomy.  He and so many other speakers are engaging, charismatic, and informative.

So we strive to be like them.  We should put our names out there, give talks, and build our brand.

The Benefits of Conference Speaking

“Build our brand” is a little wishy-washy, though, so let’s get specific.  How does speaking at conferences help you?  I have my own opinion on this, but I went out in search of others’ to see.  In broad strokes, here are some specific things that I saw.

  • Make yourself better at public speaking.  It’s like Toastmasters, but in your domain.
  • Speaking at conferences means attending conferences, and that helps you “network.”
  • Give back.  Do your part in advancement of the general cause of programming knowledge.
  • Teaching something is a great way to learn, so speaking at conferences forces you to up your game and improve your chops.

I found some blog posts on the subject offering specifics.  Scott Davis says, “the knowledge that I’ve gained from teaching workshops has been invaluable and I don’t believe that I would have been as successful with out it.”  Heidi Waterhouse says, among other things, “I also do it because I want to show up and be technical and expert and pink-haired in the world.”

That last statement, in particular, I think summarizes up the common speaker experience in the development world (though Heidi, herself, is apparently not a software developer, per se.)  Public speaking on a topic helps you acquire a lot of skills associated with speaking publicly about that topic.  And it helps you “show up in the world.”

What’s less clear is how, exactly, that benefits you in your career.

Getting Specific about Your Career and the Benefits

Now let me say something up front.  If you’re speaking at conferences for the love of the game or to generally become a better rounded person, then what I’m telling in the rest of the post will either be passive food for thought or else not entirely applicable.  For the rest of this post, I’m addressing people who are speaking at conferences to help their careers, with the idea of offering advice on how to make it help your career much more efficiently.

When listening to people tout the career benefits of conference speaking for software developers, it generally takes on this iconic form.

  1. Speak at conferences.
  2. ….
  3. Profit!

I mean, it doesn’t actually go that way.  People don’t actually say, verbatim, “you should speak at conferences and then stuff happens and then your career takes off!”  Instead, they just say that speaking at conferences is good for your career.

How so?  Well, it “builds your brand.”  Okay.  And what does “building your brand” do for you as a senior software engineer or a freelance app dev pro?  Ah, well, it’s about marketing yourself!  Better job opportunities.  Advancement.  You know, … profit!

But let’s look at what, exactly, we’re saying will arise out of conference speaking.  And also what, exactly, people put into it.

Read More


Remote Programming Jobs: How to Find Them and Why You Should

I’m going to take a break from my aggressive war on status quo wage programming jobs today.  Instead, I’ll offer something a little more how-to-y and a little more upbeat.  And I won’t once try to talk you out of salaried employment.  Instead, I’ll try to talk you into it.  Or, at least into a kind of it.  Let’s talk remote programming jobs.

Some, But Not Too Many, Words of Caution

I am, personally, an introvert.  So I always find the cautionary tales around remote work to be pretty overblown.  They go something like this.

Remote work seems like it’d be great.  And, for the first few weeks, it is!  But then you start to get lonely and stir crazy.  Before you know it, you’re heading down to Starbucks for a human connection just content to have some teenagers giggle at you.  And the weight gain?  You’re working right by your fridge!  And not to mention… [blah, blah, blah]

And it devolves from there.  I always read these posts and think of the song, Space Oddity.  You’d think these people were loading themselves into a tiny capsule and blasting off for the Kuiper Belt alone, never to see another human.

Remote programming jobs aren't like space oddity, so you won't feel like this poor astronaut, lost in space.

Look, if you’re really a group-oriented person, an extrovert, or someone who strongly prefers collaborative work, you may struggle working from home.  But then, if you’re that sort of person, you’re probably not reading this post.

If, on the other hand, you like working alone, don’t let these obligatory cautionary tales scare you.  I’ve been working mostly remotely for years and totally remotely, non-stop for 8 months, mostly in a very small town.  And I’ve never yet felt the need to hug a random barista to slake a bone-deep loneliness.

You still have friends, right?  Family?  A phone?  You’ll be fine.

Things to Guard Against

Okay, so we’ve established that you probably won’t morph into a much needier person than you’ve ever been.  But there some things around which you need to take care.

Bear in mind that these are not deal breakers, nor are they insurmountable.  They’re just things that you need to manage, especially at first, until you settle into a rhythm.

  • If you’re not used to imposing structure and discipline on yourself in terms of time management, you might need to learn this.  Maintain a schedule, set a todo list, and that sort of thing.
  • On the flip side, some people in remote situations go too far the other way and start to work all the time.  Set boundaries.
  • Depending on your work situation, you might need to get used to showcasing your contributions.  This holds doubly true if you’re in the minority as a remote worker.  Find a way to keep your boss posted on what you’re doing and your teammates engaged.
  • Remote doesn’t necessarily (or even ideally) mean that you never have facetime.  Expect to travel for meatspace interactions from time to time.

After a few weeks, you’ll settle in and find what makes sense for you, perhaps tweaking from time to time.  Just make sure to keep an eye out over the duration of your tenure as a remote worker for things that you can do to improve your productivity and interactions.

Why Remote Programming Jobs?

Alright, now that we’ve gotten the cautionary stuff out of the way, let’s move on to why you would want this.  I’ll cite my own experience, in list format, talking about the benefits.

  • Not commuting gives you back up to 2 hours per day.
  • You can work remotely from anywhere.  This year, I’ve worked from a lake in the woods, big cities, and now that it’s gotten cold up north, a house right next to the Gulf of Mexico.  You can vagabond or visit family.
  • Assuming you’re not a big time group collaborator, you’ll get work done much more productively without regular interruptions and distractions.
  • Wearing whatever is comfortable is a nice lifestyle perk.
  • Programming and similar knowledge work pursuits are deep work, which means some isolation lets you immerse yourself more in them.
  • You have a much more flexible schedule to accommodate family life or various schedule restrictions you might have.

I’ve talked about cautions, but I can’t overstate how great a lifestyle this is, provided you’re comfortable with limited professional face time.  Your life takes on a sort of freedom and autonomy that’s hard to replicate when you spend your days in an office.

But I won’t sell any further.  Let’s look at how to get yourself into a remote situation.

Read More


Corporate Realpolitik Explained: The Tech Lead

I think I’m going to start a new series of posts, with this as the first.  Leading up to and in my book, I talked a lot about organizational politics.  But I haven’t done that as much since.  I’d like to start in on that a little again, and I’ll start with the tech lead role.

Why tech lead?  Dunno, why not?

So what will I talk about?  What’s the aim here?  Well, in this post and in any future ones in the series, I want to dive into the organizational underpinnings of roles in the tech world.  This isn’t the superficial stuff you’ll see on a job description, but rather the realpolitik take.

  • Why does this role (really) exist?
  • Should you even want it?
  • How does it set you up to succeed?  To fail?

That type of thing.

A (metaphorical) tech lead, steering the SS Boaty McBoatFace

Tech Lead: The Surface Story

First things first.  Let’s cover the superficial briefly so that we can get beyond it.  If you go out and google “tech lead role” you’ll find stuff like this.

  • The tech lead has the ultimate say on technical matters for the team.
  • Part of the role involves delegating tasks to other team members as well as mentoring them.
  • You’ll obviously need strong technical skills, but also good people skills because it’s not necessarily the strongest tech people that make the best tech leads.
  • You also need to be able to communicate effectively with the business.

Got it yet?  I’ll assume you’ve never heard me speak.  If that’s the case, and you put a voice to what you just read, does that voice sound like the soothing, dulcet tones of someone from HR?  It should.

Of course, maybe you want to go the slightly more controversial and philosophical route.  Should the tech lead role even exist?  Especially on agile teams, don’t we learn that teams are self organizing?  Doesn’t Scrum call for only three roles, none of which is tech lead?

Surely we should furrow our brows and discuss this meaningfully.  On the one hand, having a communication point-person and decision maker is important.  But on the other hand, we’re knowledge workers that respond well to a more democratized approach.  So you and your organization should have an earnest and sober conversation weighing all of the pros and cons.

Of course, nobody in a decision making position will listen to this earnest conversation, because there are undercurrents in play well beyond settling arcane technical disputes out in open office plan land.

Read More


Ace Your Exit Interview Using Little White Lies of Omission

Ah, the exit interview.  If you’ve had this experience, the first one probably arose in confusing fashion.  You put in your notice and the team scheduled your goodbye lunch.  At someone point, HR put a meeting request on your calendar that prompted you to say, “an exit what — what is this?”  And then you had an exit interview.

Or, maybe you’ve never had this awkward experience at all so far in your career.

Whether you’re an exit interview veteran or googling it for the first time, though, I’ve got some pointers for how to handle this.  I’ve given general advice on whether to quit a job and how to quit a job before, but this will be specific to the exit interview portion of quitting.

What Is an Exit Interview?

First things first.  What actually is an exit interview?  It’s not the most naturally intuitive concept, but you can probably infer what it involves from its name.  Still, you might wonder, “what’s the point?”

Ah, the exit interview. Crack a beer and tell 'em how you really feel.

An exit interview is a meeting that someone, usually the HR department at a decent sized company, schedules with you.  It’ll generally happen the day of or the day before your departure, and it’ll take half an hour or maybe an hour if they really want to cover a lot of ground.

They’ll ask you a lot of questions, effectively looking for a private, Glassdoor-style review of the company.  For instance, here are some blue chip exit interview questions.

  • Why are you leaving?
  • What did you like most about working here?  Least?
  • How was it working with your manager and your coworkers?
  • Did you have what you needed to do your job effectively?
  • How could your manager improve?  How could the company?

You get the idea.  The exit interview is a standard practice for the company to collect and, hopefully, incorporate feedback from departing employees.  Theoretically, it offers them a unique window into people’s real thoughts about the company, since they can speak freely and without consequence.  Theoretically.

Read More


The Different Pair Programming Styles

Editorial note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, check out their products that help you wrangle production issues in a hurry.

The world of professional programming produces some pretty intense debates.  For example, take a look at discussions about whether and how to comment code.  We have a hard time settling such debates because studying professional programming scientifically is hard.  We can’t really ask major companies to build the same software twice, using one control group and one experimental group.  So we muddle through with lots of anecdotes and opinions and relatively scant empirical data.  Because of this conundrum, I want to talk today about pair programming styles rather than taking a stance on whether you should pair program or not.

I’ve talked previously about the benefits of pair programming from the business’s perspective.  But I concluded that post the same way that I’m introducing this one.  You can realize benefits, but you have to evaluate whether it makes sense for you or not.  To make a good evaluation, you should understand the different pair programming styles and how they work.

That’s right.  Pair programming involves more than just throwing two people together and telling them to go nuts.  Over the years, practitioners have developed techniques to employ in different situations.  Through practice and experimentation, they have improved upon and refined these techniques.

The Effect of Proficiency on Pair Programming Styles

Before looking at the actual protocols, let’s take a brief detour through the idea of varied developer skill levels.  Although we have a seemingly unique penchant for expressing our skill granularly, I’ll offer just two developer skill levels: novice and expert.  I know, I know.  But those two will keep complexity to a minimum and serve well for explaining the different pairing models.

With our two skill levels in mind, consider the three possible pairing combinations:

  • Expert-Expert
  • Expert-Novice
  • Novice-Novice

Now when I talk about expertise here, bear in mind that this accounts for context and not just general industry experience.  Tech stack, codebase familiarity, and even domain knowledge matter here.  I have two CS degrees and years of experience in several OOP languages.  But if I onboarded with your GoLang team tomorrow, you could put me safely in the novice camp until I got my bearings.

Each of these pairing models has its advantages and disadvantages.  Sometimes, however, fate may force your hand, depending on who is available.  Understanding the different pairing models will help you be effective when it does.  It also bears mentioning that novice-novice pairings offer a great deal of learning for both novices, but with risk.  Therefore, the suitability of such a pairing depends more on your appetite for risk than the pairing model.

Read More