DaedTech

Stories about Software

Dec
3

By

Hacking Your Career as a Non-Developer

Category: You Asked For It |

It’s Monday again, which means another Reader Question Monday.  This week, rather than renew my assault on all things sacred to software developers, why don’t I mount an assault on the design profession?

I’m kidding about the assault part.  Probably.  But today’s question comes from a designer.  I consider this cool because we knowledge workers should band together and because I’m glad that people beyond software developers read the blog and my book.

Here’s the question.

Loving Developer Hegemony – tons to think about.  I would love your thoughts on this situation.

I’ve applied for a green card, but that means I’m unable to leave my current, underpaid job.  I’m also stuck with the ‘designer’ branding through the eyes of execs, and the CTO (owner), who I report to.

What’s the best use of my time?

Inspired by your book I’d like to at least experiment with distancing myself from line-level design work, but I also don’t want to over-work, as my current deal is economically terrible, and I’m obviously an unlikely candidate for promotion.  Is it a matter of smartly deferring loser-work and snapping up, or inventing the ‘best’ projects for me, while cultivating my external network and side projects?

I’ve been pushing your book on the devs I work with – but most of them are too idealistic!!

First of all, thanks for your support buying the book, for reading the blog, and for your question.  Let’s get you some answers.

Examining and Inferring the Nature of Your Organization

First of all, a few things about this scream small-ish, perhaps not super-mature startup type of shop.  Why do I say this?

  1. Executives are interested in what (no offense) some line-level designer is doing.
  2. You regard the CTO as an “owner” rather than a shareholder or even co-founder.
  3. You’re underpaid.
  4. You report to the CTO.

Of course, the operation can’t be too rinky-dink, which I infer from the following.

  1. You say devs, plural.
  2. You have a staff role as a designer instead of a part time/freelance deal.
  3. They’re sponsoring foreign workers.

Why do I mention all of this?  Well, it’s good to establish some axiomatic context for the readership.  But it’s also important to paint a picture related to the corporate hierarchy that I so frequently reference, both in the book and on the blog.

You are, quite probably, in a company with an anemic idealist buffer between pragmatists like yourself, and the controlling opportunists.

Read More

Nov
30

By

DaedTech Digest: Analysis Rules, Singletons, and Log Aggregation

Category: Uncategorized |

Happy Friday, DaedTech readers!  Time for yet another installment of the DaedTech Digest.

I didn’t do one last week because of the US holiday.  For those of you not from the US, there’s this holiday called Black Friday that everybody celebrates by getting together and eating turkey the day before and then subsequently bludgeoning one another in retail stores the next day.  Out of respect to this noble tradition, I held off on making a post.

At any rate, it’s been a busy couple of weeks in my world.  We’ve migrated south for about 5 weeks and are living in a beach town on the Gulf of Mexico.  This photo below is a shot of where I’m working from today as I type this post.

So life is good.  With that in mind, let’s get to picks.

Picks

  • The jury isn’t totally back yet on this, but we’re trying out FreshBooks for managing Hit Subscribe‘s books.  And, so far, it’s great.  And it integrates with other favorite Gusto besides.
  • I’ve been listening to an Audiobook called How to Measure Anything, and enjoying it.  Any consultant worth his or her salt spends a lot of time figuring out how to quantify problems and solutions, and this is definitely helpful.
  • The folks at a site called Data Camp reached out to me about the study I’m doing over at the NDepend blog.  They seem to be developing a cool offering for teaching people about data science using Python and R.
  • I also pick time off.  I work very much on my own schedule and generally not full 8 hour days anymore.  But I also do tend to work 7 days a week.  Last weekend, Amanda and I played tourist and did nothing but explore the Gulf Coast, buy fresh seafood off of piers, dine out, explore new cities, and walk through state parks.  This was nicely restorative.

DaedTech Post Digest

  • In my consulting (and even long-ago salaried) travels, I’ve encountered a lot of myths about code reviews.  I wrote a post for the SubMain blog in which I looked at some of those.
  • I wrote a post for NDepend, in which I explored a topic probably not many have.  What’s the role of static analysis in your testing?   These things might seem orthogonal, but I think they actually have an interesting relationship.
  • Also for SubMain, I did a post in the CodeIt.Right Rules Explained series.  I examined why you should avoid single line if statements, why you shouldn’t base your enums on weird underlying types, and the problem with explicit rethrows.  All of this in C#, BTW.
  • In a post that went a little viral and predictably resulted in people calling me a know-nothing incompetent, I wrote about what the singleton design pattern costs you.  This was for the NDepend blog, again.  (But I’d have the last laugh later, when I would actually study it empirically and prove myself mostly right — stay tuned for that in a future digest.)
  • In a much less controversial post (because they don’t enable comments), I made the business case for unit testing on the ASPE blog.
  • For Scalyr, I wrote a post about log aggregation.  What is this, why would you want it, and how does it help you?

And, that does it for the digest round up.  Have a great weekend!

Nov
28

By

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

Category: The Life of a Programmer | 11 Comments

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

Nov
26

By

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

Category: Free Agent Developers, You Asked For It | 17 Comments

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

Nov
21

By

Corporate Realpolitik Explained: The Tech Lead

Category: The Life of a Programmer Tags: | 2 Comments

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

« Older Posts
Newer Posts »