DaedTech

Stories about Software

By

Contrary to No One’s Demands, I’ll Blog about Whatever I Please

Since switching the reader question responses to Tuesdays, I don’t blog on Mondays.  Today I’m going to make an exception to write sort of a meta-post.

Categorizing it as an “announcement” would be a little too grandiose.  Instead, it’s kind of an explanation for my regular readers and something that I may link back to in the future for reference.

I’m reconsidering how I think about the DaedTech blog.

I’m Not Doing Anything Drastic with the Blog

Having said that, let me pump the brakes on any speculation about a pivot.  There won’t be one.  I’m not going to suddenly start blogging about knitting or something.  I’m not going to monetize the blog in a different way (except that I did recently remove the paid ads from DaedTech).  And I’m definitely not going to stop blogging.  I honestly don’t think I’m capable of not writing.

I mean it when I say I’m reconsidering how I think about the blog.  I’m going to start approaching topics differently and writing somewhat differently.

In short, I’m going to back for writing this blog purely for the fun of it.

Read More

By

Junior Developer: The Title You Should (Almost) Never Accept

I’ve had sort of a hate-hate relationship throughout my career with the title of junior developer.  Wait, that’s too nuanced.  Remove the “sort of” — I’ve just had a hate-hate relationship with the term.

This isn’t a job title you should accept, unless you have your back against the wall.  A prospective employer might say to you, “congratulations, we’re offering you a junior developer position!”  Treat this equivalently to “congratulations, we’re offering you a position at $10,000 below market value!” or “congratulations, you’re on your own for health insurance!”

If you’re hard-up, take it.  But keep your job search going full throttle, and keep your current “junior developer” role off your resume.  If you don’t have mouths to feed and rent to pay, take a pass.

Why?  Well, I’ll get to that.

Regular developer patting a "junior developer" (actually a toddler) on the head

Junior Developer Title on My Mind

Last week, unprovoked, I tweeted out my opinion of this title.  I don’t need to rehash that tweet here, since I’ve already explained my stance here.  But I got a thoughtful and reasonable question in response.

I didn’t respond to this because I’m terrible at Twitter.  In fact, I didn’t actually notice it for days and then I got busy.  I thought to respond at that point, but then I realized that I’m enough of a blabbermouth that I’d adjudicate myself much better in a blog post of 1,000+ words than I would in a tweet of 280 characters or fewer.

Then, coincidentally enough, someone mentioned me in another tweet (that I also didn’t notice for a while).

“How do you reward junior devs that are kicking ass?”

My initial, off-the-cuff thought?  Stop calling them “junior devs,” for God’s sake.  But I didn’t get the sense that was appropriate for the conversation.

Instead, I think it’s appropriate here, in a post telling you not to accept this title.

Read More

By

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

By

Whiteboard Interviews: How to Avoid Them and Improve Your Career

As I mentioned last Friday, I’ve lost track of the number of folks who have shared Michael Lynch’s piece about quitting Google with me.  I suppose I should expect that, since I often rail against hiring practices that people associate with Google and similar companies.  This includes the titular whiteboard interviews, of course.  And, for good measure, I’ve even written a book in which I suggest simply not agreeing to do this style of interview.

Interestingly enough, though, I don’t have anything in particular against Google at all.  Nor do I have anything against its contemporaries, all of whom I am coming to think of as Enterprise Silicon Valley, given their legacy of innovation combined with their increasing resemblance more to the IBMs and GMs of the world than the hottest new startups.  I wouldn’t agree to interview at these companies, but that doesn’t mean I don’t like them.  I mean, I like Chrome and Gmail and have an Android phone — keep pluggin’ away, guys.

I’ll even go so far as to say I don’t begrudge companies using whiteboard interviews nor do I think that it’s a bad idea for them to do so, in some cases. 

But I’ll come back to the nuance of that later, leaving a dangling question of my hypocrisy until I do.  In the meantime, I want to share a tweet and a story of my own failure to follow up on messaging.

A Twitter Conversation about Breaking into Software

Amid my (now often overwhelming, sorry to anyone who tweets at me and I don’t see it) mentions on Twitter, I noticed this one from a few days ago:

That’s true.  In the part of Developer Hegemony where I explain my take on the path to, well, developer hegemony, I offer that advice.  Simply refuse to do whiteboard interviews.  Define and manage your career in such a way that you don’t need to do them.

The book covers a lot of ground, so I don’t place a ton of detailed emphasis on that point.  But I think that I should have followed up with some content that did.

Zoom out and look at the conversation.

Melissa’s tweet comes in response to someone named Daniel asking about resources for breaking into the programming world.  He appears to be attempting to synthesize the advice of people in that world, concluding that, no matter what, breaking in requires knowledge of “data structures [and] algos.”

I’ll leave it as a reader exercise to consider whether entry level work banging out forms-over-data web apps requires theoretical computer science experience.

Read More

By

Software Craftsmanship as a Metaphor is a Career Glass Ceiling

Is software development a craft?  I think this might be a decently long post, so let’s come back to that, to journeyman idealists, and to some of the finer points of what counts as “software craftsmanship” a little later.  Before that, please indulge me in story time.  Or, backstory time, as it were.

About 7 years ago, I digitally “signed” something called the Manifesto for Software Craftsmanship.  Go do a search, if you like.  I’m signatory number 6,662.  I remember submitting that form with something like quiet but fierce indignation in my soul.

Software Craftsmanship as Caring and Professional Pride

The year was, according to the website, 2010, and I was surrounded by expert beginners.  These folks made architecture decisions on the basis mainly of seniority.  The longer you’d hung around the company, the more conceptual votes you ‘earned,’ for some dubious definition of the word earn.

The result?  A codebase littered with global state, spaghetti, beachheads of copy-paste code, and tortured, meandering God classes.  It was like a bomb went off in that codebase.  And if you wanted to try to fix it with newfangled concepts like writing unit tests or paying attention to method complexity, you’d hear predictable expert beginner fare.  “I’ve been doing this for a lot of years, and I’ve been shipping software just fine without any of that stuff.”

In that role, I slowly earned my way into positions of influence and then decision-making before I left.  At the time of my eventual departure, the build executed a growing unit test suite, interfaces existed in the codebase, and I was proud of what I had done.  But it was hard fought and exhausting every step of the way.

And I probably wouldn’t have lasted as long as I did without the galvanization of the software craftsmanship manifesto.  It spoke to me, and it said, “not only is it okay to care and to have standards — it’s your professional obligation.”

My Evolving View of Software Craftsmanship

As recently as last April, I wrote a post about software craftsmanship making for good business.  As a salaried software developer (and company of one, ala Developer Hegemony), you ingratiate yourself more to the business by adopting practices like TDD than you do by competing in algorithm trivia contests that no one who matters can referee.  You start to trade in tight feedback loops, predictable deliveries, and things that make your “clients” really happy.  And you become more marketable as an app dev pro.

And years before that, I defended the software craftsmanship movement against a detractor.  In that post, I argued that the real thrust behind the movement was to establish that software development isn’t an insolvable quagmire of relativism.  Some practices work better than others, and to pretend that isn’t true amounts to quackery, and we shouldn’t tolerate quackery.

In general, if you go back far enough on this blog, you’ll find a bunch of references to software craftsmanship.  And in these references, you’ll find some themes.  I’ve always respected the caring behind the movement, and I’ve always valued the practices: TDD, continuous integration, constant refactoring, etc.  And, whenever I talk about software craftsmanship in praising terms, I’m always talking about those practices and the caring that drives them (including in the post about software craftsmanship being good business).

But, truth be told, I’ve never had much use for the term “craftsmanship,” per se.  Historically, I didn’t give it much thought one way or the other — it was just branding, like “agile” or “lean.”  But over the years people have started to fetishize the craft guild metaphor into titles and practices and even into a philosophical way of looking at software.

And if you fall into this trap, you do so at your career’s peril.

Read More