DaedTech

Stories about Software

By

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

By

Learning in a World Where Programming Skills Aren’t That Important

After a couple of weeks doing Reader Question Monday on a Tuesday, I’m back on track.  I’ll briefly congratulate myself before moving on to the potentially pot-stirring topic of programming skills.

Today’s question is one I’ve gotten a LOT, but have struggled to answer.  I didn’t want to write on the subject until I had what I considered to be a coherent, defensible position.  So I’ve pondered and stewed.  And I think I’m finally ready to answer.  Be warned, though.  This post will probably be lengthy and, at times a bitter pill.  But I think it’s important.

Here’s the question, as a composite from all of you who have written me about it.

How will experience work, especially at the entry level, in the efficiencer world?

What on Earth is an Efficiencer?

A little background, for anyone who isn’t up on secret language of the DaedTech blog.  Efficiencer is a neologism that I used to describe what I perceive as the more business-savvy, more autonomous software developer of tomorrow.  I’ve written a number of posts about it, but I actually defined the term in my book, Developer Hegemony.

Briefly, efficiencers are different — more — than programmers.  Programmers ingest specs and spit out source code.  Efficiencers solve problems.  To illustrate, consider the following.

  • You go to a programmer and say, “I need an ASP MVC website that uses Entity Framework, .NET Core, and SQL Server on the backend.”  The programmer says, “sure, boss, give me the wireframes and I’ll code it right up for you.”
  • You go to an efficiencer and say, “Right now our company takes all of our orders over the phone, and our website is purely ornamental.  I don’t know how this will work, but I know that we need the ability to take orders over a website, 24 hours a day to keep up with our competition.”  The efficiencer says, “I help businesses like yours automate their ordering process, so don’t worry, I’ll make sure your site not only competes with, but outperforms, those of your competitors.”

Can you spot the difference?  Can you tell which professional needs six layers of management and bosses in order to do anything useful, and which one IS the boss?

The Conundrum of Entry Level Efficiencers

The programming world of tomorrow is one in which we, as software developers, stop being the least important people in the software development industry.  In my book and in general, I propose a future in which efficiencer firms, structured like law firms, consist of efficiencers (professional automaters) who call the shots and delegate things like project management (status reporting and schedule coordinating) to subordinates, instead of superiors.

That has resonated with a lot of people.  People like the vision in general, but it leaves a lot of folks wondering about the question that is the subject of this post.

What does entry level efficiencer-hood look like?

The Efficiencer Career Plan in the Short to Medium Term

I won’t bury the lede any further.  I’ll answer the reader question here, in this section.  What will follow for probably thousands of words after that is an explanation and the pot-stirring controversy that I mentioned.  You’ll see why I need to explain further after reading the efficiencer career path.

  • Skip a CS program, because that’s not worth the investment anymore.
  • Do whatever is necessary to get yourself an entry level programming job.  (Boot camp, lateral transition, self-taught, whatever.)
  • Spend 2-4 years as a corporate programmer in a few jobs, where you get paid to learn programming.  This is kind of like a doctor’s residency: you’re an actual programmer in the wild, but also a student.
  • Quit your job and become an actual efficiencer because 2-4 years is plenty of time to become as good at the general skill of “programming” as anyone needs to be.  After your employed residency, you should start to focus on your particular specialty and on growing your brand/career/business.

Alright, deep breaths.  To channel emperor Palpatine, “I can feel your anger.  It makes you stronger, gives you focus.”

Like Anakin here, I can feel your anger at the idea that programming skills aren't as valuable as you think.

How can I possibly make this claim?  2-4 years of programming is barely enough not to make a mess, let alone to perfect this elusive craft.  Am I out of my mind?  Or maybe just an idiot?

Read More

By

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

By

Get Work Done: Strategies for Getting More Efficient and Finishing

For the second week in a row, I’m tackling reader question Monday on a Tuesday.  This time, my excuse involves the mini-move my wife and I made over the weekend that I originally mentioned on Friday.  So traveling, unpacking and all that.  But, better late than never.  Today, I’ll talk about how to get work done.

Here’s a reader question that I received a while back.

Hello Erik!

I enjoyed your article on 10x developers. Environment is very much a large part of the equation.  My current question is:  What is the ideal way to increase one’s software efficacy? To increase their doneness?

A little context is that I’m feeling the need to become more “effective”. In the words of Steve Yegge of the “done, and get things smart” dichotomy, I’m comfortable getting things smart. I like cleaning up code and make systems more readable, leaving documentation, and removing hurdles for the team. But it takes me a long time to do so.

I’m at a startup venture right now and will be here for a year or two longer. After that I’d like to take a month off, then spend a 3-6 months (or maybe longer if the solution requires it) focusing on ‘closing the loop’, getting more stuff done, being a better programmer.

Some possible options I’m considering:

  • Finding a new job with this as primary motivating factor
  • Apprenticeship at 8th light or similar
  • Grad school
  • Some dev bootcamp
  • Self direction + contracting
  • Finding mentorship here

I would love to get your thoughts, if you wanted to increase your general ability to get things done, how would you do it? Where does one learn to get things done?

Clarifying “Get Work Done”

First of all, let’s do a bit of clarification.  In his blog post, Steve Yegge riffs on Joel Spolsky’s “smart and gets things done” theme.  Steve’s take about “get things smart” refers to burrowing into existing systems and improving them — making them smarter.

So the reader question here is envisioning a spectrum of sorts between “done” and “smart.”  When forced to choose someone on the “done” spectrum would opt for quick and dirty.  On the other hand, the “smart” folks would perhaps push the deadline in favor of having uncompromising standards.

You could interpret this question as “how do I stop perfecting and start shipping?”  But I think it’s more than that.  It’s a question of, once you’ve figured out how to “get things smart,” how do you get them done more efficiently and know where to make trade-offs?

So let’s take a look at that.  What are some strategies deliver more stuff?

Read More

By

DaedTech Digest: Code Quality, Feature Flags, and Physical Migration

Happy Friday, everybody.  It’s DaedTech Digest time today.

I am just wrapping up my work week and preparing to spend all day tomorrow (today, by the time you read this) driving south to the US Gulf Coast for the next 5 weeks.  Why?  Because it’s cold where I am in Michigan, and it’s not cold down there.

We’re planning a winter/early spring where we split time between a town called Bay St. Louis, Mississippi, San Diego, and Mesa Arizona.  So if you live in any of those places and have suggestions for places to go or meetups to attend, I’m all ears!

Picks

  • If you like posts along the lines of the one I made Wednesday, then I suggest a couple of podcasts.  First, the Freelancer’s show, and second, the podcast of one of the panelists, Jonathan Stark, called Ditching Hourly.  They talk a lot about positioning, marketing, getting business, and getting away from the trap of hourly billing.
  • If you have any interest in SEO and keyword research, I recommend a Chrome plugin called Keyword Keg.  I use this constantly for my content business to help look for good blog topics.  When you do Google searches, it shows you the keyword volume right inline.
  • Speaking of my content business, I’ll do a plug for the Hit Subscribe blog.  The blog is aimed at teaching techies to use blogging to advance their business interests.  So if you want to learn about blogging, give it a look.
  • On the coding side, I’ve been enjoying Shouldly a lot for its unit testing assertion semantics.

DaedTech Post Digest

Have a good weekend!