DaedTech

Stories about Software

By

Learning with Hands on Projects

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, take a look around and download NDepend to try it out.

If you want a surefire way to make money, look for enormous disparity between demand and supply.  As software developers, we understand this implicitly.  When we open our inboxes in the morning, we see vacuous missives from recruiters.  “Hey, dudebro, we need a JavaScript ninja-rockstar like you!”

You don’t tend to see vaguely patronizing, unflinchingly desperate requests like that unless you sit on some kind of goldmine.  They approach us the way one might approach a mischevious toddler holding a winning lottery ticket.  And, of course, anyone would expect that with wildly disproportionate supply and demand.

But, for us, this transcends just writing the code and oozes into learning about it.  Like baseball teams playing the long game, companies would rather grow their own talent than shell out for high-priced free agents.  And so learning about software might just prove more of a growth industry than writing it.

Look at wildly successful industry player Pluralsight.  It has built a benevolent commercial empire on the simple promise of democratized learning about technical pursuits.  Then you have a host of fast followers, an army of boot camp providers, and endless how-to blogs.  Sometimes it seem as though a gigantic wave of pressure pushes us all toward writing a bit of code.

The Learning Tools in Your Tool Belt

Let’s say that you’re convinced.  You see the money to be made, or you simply feel drawn to the profession.  You want to get involved, but don’t quite know where to start.  What sorts of learning can developers avail themselves of?

While I won’t call this an exhaustive list, I can offer some general categories of learning.  First, consider theoretical, passive learning.  You crack open some book called, “Principles of Modern Web Development” and get to reading.  Second, you have classroom-style learning.  An instructor leads your lessons, curates information, and engages you in Q&A.  And, third, you have hands on learning.  With this kind of learning, you put actual concepts into practice.

Understand that I do not consider these mutually exclusive by any means.  Any serious leaning plan worth its salt is going to incorporate elements of all of these (and probably other form categories that escape me at the moment).  But understanding the flavors will inform the rest of this post.

Read More

By

Moonlighting as a Software Developer: Getting Started

I think I’m now on enough of a roll to stop lavishing praise on myself for sticking to reader question Fridays.  So I’ll just get right to business.  Today’s question is about moonlighting as a software developer.  It’s short but sweet.

Any tips for finding moonlighting opportunities?

Sure!  Let’s do that.

Defining Moonlighting

First, though, I want to make it very clear what we’re talking about here.  Moonlighting isn’t a synonym for freelancing or contracting.  Instead, it has a very specific connotation.  You can look to the dictionary for the technical specifics.  Emphasis mine.

Paid work that you do in addition to your normal job, especially without telling your employer.

To unpack, we have a core component and a second, common one.  You do work in addition to a salaried job, and usually without informing your primary employer.

For the rest of this post, I’m going to assume that you don’t want your primary employer to know that you’re doing this.  I’m also going to assume that we’re talking about moonlighting related to your software development work and not you getting a cashier’s job at the local bodega.  You make a living as a techie and want to earn some additional cash, also as a techie.

A programmer moonlighting... literally.

Read More

By

The One Thing Every Company Can Do to Reduce Technical Debt

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, take a look at the technical debt functionality in the latest version of NDepend.

The idea of technical debt has become ubiquitous in our industry.  It started as a metaphor to help business stakeholders understand the compounding cost of shortcuts in the code.  Then, from there, it grew to define perhaps the foundational of tradeoffs in the tech world.

You’d find yourself hard pressed, these days, to find a software shop that has never heard of tech debt.  It seems that just about everyone can talk in the abstract about dragons looming in their code, portending an eventual reckoning.  “We need to do something about our tech debt,” has become the rallying cry for “we’re running before we walk.”

As with its fiscal counterpart, when all other factors equal, having less tech debt is better than having more.  Technical debt creates drag on the pace of new feature deliver until someone ‘repays’ it.  And so shops constantly grapple with the question, “how can we reduce our tech debt?”

I could easily write a post where I listed the 3 or 5 or 13 or whatever ways to reduce tech debt.  First, I’d tell you to reduce problematic coupling.  Then, I’d tell you to stop it with the global variables.  You get the idea.

But today, I want to do something a bit different.  I want to talk about the one thing that every company can do to reduce tech debt.  I consider it to be sort of a step zero.

Read More

By

The Hidden Costs of Slow Websites

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look at all of the different monitoring solutions they offer.

The world seems to conceive of a curious bubble separating IT from “the business.”  More so than just about any other pursuit in the commercial world, people think of IT as some kind of island.

It thus becomes easy to conceive of IT goals existing in a vacuum.  “We should optimize the database so that it becomes better.”  “We should make this software work on all platforms.”  The part about “… because that will help us make money” seems never to materialize.

Agile methodologies like Scrum seek to address this separation by encouraging tight interaction between IT and business interests.  Doing this closes the loop between technical actions and profit motives.  “We should make this software work on all platforms in order to increase revenue by 50%.”

If we look at the world of company websites, we can find the ubiquitous argument for faster page load times.  “The site should load faster.”  Today, I’d like to make the business case for why we want this.

But I’d like to dig a little deeper than the most obvious cost.  To understand that, consider articles like this one.  Users tend to bounce in the face of multi-second page loads.  As a result, slow performance could cost a high-throughput giant like Amazon billions of dollars.

I doubt that news shocks you.  So, instead, let’s take a look at more subtle ways that your business can lose money via a slow site.  Let’s examine hidden costs of slow websites.

Read More

By

Starting a Software Company from Scratch

When I reflect back on my free agent career, it strikes me that I more or less did everything wrong.  I mean, I don’t actually believe that when I look at it analytically.  But it does feel that way, knowing what I know now.  Starting a software company from scratch invites plenty of missteps.

In the lead into last Friday’s reader question post, I talked about starting this blog as a journal of sorts.  That’s a good example of what I’m talking about.  In the end, I built an audience, established a brand, and wound up in a good place.  But if I could go back in time 7 years and give myself advice, my path would have been more direct.

It goes beyond blogging, of course.  That was one example, but it applies generally to my entire approach to starting my software development/consulting company.  I did things that worked out, but it hardly seems optimized in retrospect.

You’re probably thinking that this applies to everyone.  Hindsight is 20/20 and all that.  And you’re right, which is exactly my point.  I dove in with severely imperfect knowledge, made a lot of mistakes, and it still worked out pretty well.

If you pursue the free agent life, you’ll flail, make mistakes, and have some false starts.  But you’ll recover, figure it out, and do fine, even if it sometimes seems like you’re drowning in the moment.

Flat Squirrels and Driving Directions

Perhaps you’ve heard an expression.  “Be decisive. The road of life is paved with flat squirrels who couldn’t make a decision.”  Don’t blame me for the macabre nature —  I didn’t make it up.

I like part of the sentiment, but I think it misses the mark slightly.  If you picture a terrified squirrel in the road, its biggest problem is thousands of tons of steel and plastic death bearing down on it.  It starts left, then moves right, then freezes and then… well, you get it.  Indecision costs it dearly, but only once it has a large problem already.

When starting a software company from scratch, indecision won't flatten you, but it will impede your progress.

This probably doesn’t describe you in most situations that call for more decisiveness.  We face paralysis by analysis, rather than paralysis by mortal terror.  Have you ever sat in your car, debating whether to take the highway or side roads during rush hour?  Have you ever sat there debating this for so long that you get to your destination later than if you had simply picked either option and started immediately?  (Come on, I bet you have.)

This makes for a better analogy for our lives, especially when it comes to starting something new.  We put off action out of fear of taking a sub-optimal path.  But, at some point, even a sub-optimal path beats sitting in your car fretting.

Read More