Stories about Software


How to Get a Programming Job without a Degree

This week’s reader question Tuesday is a look at how to get a programming job without a degree.  It’s probably a good one for me to hold forth on.  In my book, Developer Hegemony, I argue that, in spite of my own two CS degrees, I probably wouldn’t recommend that course of action to prospective programmers nowadays.  It’d be hard to justify ROI on it, especially at expensive schools.

So if you don’t get the degree, then what?  Here’s the reader question.

How do I get a job without a CS degree? The only entry level postings I see require a CS degree. When I look for how to get a job without a CS degree I see lots of information on education. They say to read books and write code and that’s great. I’ve done all that. I know how to code. Now where do I apply? I don’t see anyone hiring entry level without a degree.

First Things First: Why Don’t Companies Make This Hire?

You might think that companies would at least give you a crack at the entry level via the interview.  You tell them you can code and you understand if they don’t simply take your word for it.  Isn’t that what the interview is for?  To allow you to prove it?  And, wouldn’t this be doubly true since the demand for programmers far outpaces the supply?

This makes sense at sort of a macroeconomic level.  But it actually breaks down a bit when you look at any individual company.  Yes, an individual company probably needs more programmers than it has at any given moment.  And yes, the the interview process, theoretically, should give any potentially qualified candidates the chance to prove themselves.

But individual companies are optimizing far more to avoid false positives than they are false negatives.

Companies Avoid Brillant Paulas

The job interview is, frankly, a terrible way to find talent.  It consists of strangers seeing how generous they can be with the truth without technically lying to each other followed by gut feels, snap impulses, and other assorted non-scientific things.

And, while all companies like to kid themselves into thinking they’re good at this, on some level they know they aren’t.  They know that, for all of their efforts, they’re going to whiff occasionally and hire a Paula.

Hiring Paula is embarrassing.  So the candidate search process has evolved to optimize to minimize complete whiffs and make them understandable if they happen.  If you hire someone with 2 “senior software engineer” titles on his resume and 10 years of experience, how were you to know?  Likewise, if you’re hiring at the entry level, and you hire someone with a CS degree… how were you to know?

But if you hire someone with no experience and no degree and they turn out to be Paula, well, then you look pretty silly.

So our mission here today is to figure out you can minimize the degree to which hiring you could look silly.  That’s what gets you interviews and eventually offers.

Read More


DaedTech Digest: Codebase Research, Experimenting in Production, and Vortexes

What a week.  Last weekend, we packed in a lot of activity, continuing our Phoenix experience.

On Friday night, we saw a Diamondbacks game, which included fireworks, and then explored downtown Phoenix.  We then packed up for a day trip to Sedona, Arizona, which is a couple of hours away.  Sedona is a town of about 10,000 people or so, and it’s got sort of a charming-ish downtown area.  But it’s really a destination because of the landscape.

Sedona is known for its red rock formations, cliffs, mountains, hiking trails, and views.  It’s also known for something called “vortexes” that are, apparently, torrents of “spirtual energy” or something like that.  I won’t go into this because it’s not really my thing.  But if you like the energy of mother Gaia or whatever, it’s probably got something for you.  But you don’t need to believe in spiritual vortexes to appreciate the scenery.  Here’s what you can see from one of them.

Our whole day was filled with hiking and this sort of scenery.  And it was wonderful, especially in contrast to the 4 days that would follow, when I worked 14+ hours each day.  But, onward and upward.


  • I caught a pretty interesting episode of the Freelancers Show this week.  They talk about something called “The Introduction Game,” which I highly recommend if you’re trying to figure out a specialty.
  • If you ever need to export a blog post from WordPress, this plugin is pretty simple and it gets the job done.
  • I pick Chase Field, if you’re ever in Arizona.  It seats something like 50,000 people, which is way too many for the average baseball game.  The result is an uncrowded, pretty luxurious baseball experience that’s admittedly not super intimate.  But it’s definitely a comfortable and inexpensive way to see a baseball game.

The Digest

Happy Friday, and have a good weekend.


How to Get Yourself Out of Technical Debt

This week, for reader question Tuesday, the question couldn’t be simpler.  It’s about technical debt, and here’s how it goes:

How do you get out of tech debt?

I told you it was simple.

I’ve talked about technical debt a number of times on this blog.  I offered my own definition years ago (in another reader question, actually).  I’ve talked about why it exists, and I’ve written at times about how you can use NDepend to identify and quantify it.  But I guess I’ve never really talked in any detail about how to escape it.

Let’s do that today.

Read More


DaedTech Digest: Pairing, Code Readability, and Writing My Own Code

Well, it was a good run going to lots of baseball games.  But Cubs’ spring training ended (at least here in Phoenix) on Sunday, so I’ve resumed somewhat of a normal working life.  At least, what passes for normal working life when you’re a remote-working nomad.

And return to work I have!  It’s been a relatively tiring week of working from waking up until going to bed, minus breaks to go jogging along a waterway in Phoenix (pictured below) and to eat.  I don’t recommend this sort of thing for work-life balance.  And I certainly don’t recommend it unless it’s in pursuit of building your own empire, rather than an employer’s.

But I got to spend some time writing code this week, which makes it all sorta worth it.


  • Just today, I followed this guide to using the Google Sheets API in .NET.  It involves some pretty easy setup, sample code, and the installation of a NuGet package, and you can get going easily in a few minutes.  This is a nicely polished getting started guide.
  • I’m going to throw a pick to StubHub for baseball game tickets.  I’m not in love with their app, per se, and I’m really not in love with their default setting of signing you up for teams’ mailing lists.  But their app has completely and seamlessly eliminated the need to mail/print/carry paper tickets.

The Digest


A New Way to Measure Software Careers

How do you measure the progress of software careers?  I don’t mean rhetorically — give it some thought.  As a software developer working your way through the workforce, subconsciously optimizing for AMP, how do you evaluate yourself?

I can think of some things that probably flash into your head:

Maybe you have others.  Weigh in below in the comments if so — I’m honestly interested to hear.

Anyway, today, I’m going to propose a different one.  At first blush, this measure seems kind of binary.  But I think there’s actually a subtle continuum, and this post will explore it.

So, how do I propose we measure progress in software developers’ careers?

Simple.  Your career is as mature as the degree to which you control the decision about whether or not to write software.

What Does It Mean to Decide Whether or Not to Build Software?

Before I get into the progress spectrum I mentioned, I should probably justify my assertion and elaborate a bit.

First of all, when I talk about the decision about whether or not to write software, I don’t mean it in some kind of granular, micro-sense.  I don’t mean that you have the autonomy to decide whether to roll your own logger or to use Log4j.  I don’t even mean that you’re an architect and you can push back on the business about technical feasibility in the short term.

No.  I mean that you make the business decision about whether or not to write software.

For instance, say you’re a free agent that specializes in helping mom and pop retailers establish an online sales channel.  When Mom’s Gourmet Macademia Nuts calls you and contracts you to help, you decide whether to build a custom web app, use Shopify, or send them to Etsy.  (Or whatever — this isn’t exactly my forte.)  Mom asks you for help, and you decide whether or not writing software should be part of that help.

Or take me and my content business, Hit Subscribe.  In order to earn my CTO designation on LinkedIn, I’m handling the business’s technical decisions, including whether to delegate tasks, automate them with off the shelf products, or build custom automation myself.

That’s what I mean about the build decision.

Read More