Skip to main content

Posts

Teams and Complexity

Let's pretend you're a car mechanic (I don't know, maybe you are).  But you don't work at some shop in town, you work at a bigtime auto-maker onsite at the factory.  You help build cars from scratch.  You work with a lot of other car mechanics, and various engineers of different levels.  If we were looking at the 1910s, you might be working for Henry Ford on one of the first ever assembly lines.  Either way, you have a specific part of the car you're responsible for.  Your skills probably extend beyond that, and you might work on a different part of the car each day as your manager moves you around to keep the factory efficient.

One of your coworkers, Bob, is a superb engineer.  He is very good at building cars, far better than you, and he does it faster than everyone else.  Your boss really likes him.  You often get stuck after him in the assembly line, so you know exactly what sorts of things he does.  He's not sloppy, but he likes to do things his way.  He w…
Recent posts

Managing Developers is HARD

I've been a software dev for a long time.  I've also been running my own software company for a few years now.  This is important information because of why I do these things.  I am a sofware developer because I love learning.  I slack off when doing a job that bores me, and software development always has something new to experience which keeps me excited and interested.  Why start a software company then?  That puts me in the role of manager rather than developer.  The truth is simple.  I've worked for a lot of companies, and I don't see any of them doing a great job of managing their software development.  That's not to say none of them have done a good job, but no one out there seems to be doing a great job.

How are they different?
A lot of companies get this part right.  Software developers are different from other employees.  The distinction is important in the same way it's important to acknowledge that an insurance agent is different from a construction…

When Is Software Done?

I have some very exciting news.  A piece of software I've been working on for over 2 years is released to the general public!  This is a little exciting if it were software I'd been working on for some big company.  It's very exciting because it's software I have been working on for my company.  That's right!  My company is ready to start selling software and start making money!

I'm not gonna use this blog post to talk about my company and what it does.  You can read about that in our press release.  Instead, I'm going to talk about the software industry and the concept of done.  Because, as with everything, it's more complicated than it seems.

Software is never really done
Actually that's a misnomer.  Software can really be done.  But done is sort of a quantum state--there and not there at the same time.  First and foremost, anyone can understand that software that works is complete.  If the software's purpose is to process a credit card, if th…

Encrypt All The Things

I love to study new technology as it comes out, but today's blog post is about a very old technology finally being handled in an intelligent way.  Let's start with the old technology.

It's all https
Security on the internet is hard to explain, but in general it just--sucks.  The truth is that when you log into you bank's website, the data to handle that is (usually) encrypted.  That is to say that the data your'e sending to the bank is gibberish that the bank's servers know how to translate back into your username and password, among other things
Encryption is complicated, but the important thing to understand about all of this is that your computer has to know how to translate your username and password into gibberish, and the bank's computer has to know how to translate that gibberish back into your username and password.  For this to happen, those computers have to start by sharing the translator with each other, we call this the handshake.  Usually, it …

Your code smells? Let it!

Code smell is a term used pretty commonly in software development.  It is a way for one developer to express to another that they're experience is telling them something is wrong, even though they don't see it on the surface.  In fact, that's what it's supposed to mean.

But software developers don't do well with "trust your gut" as a methodology, so we make an effort to identify and quantify things like this.  For that reason, over time we have managed to put together lists of things in your code that are "code smells" and explain why we don't like them.

For illustration, I'm going to refer to personal experience and talk about an application I'm currently working on.  A common code-smell that developers will talk about is singletons.  So that will be the basis for my example, but the message should be clear even without the example.

Why does it smell?
The first thing you should ask the developer on your team who's most knowledge…

Dependency Injection - You're doing it wrong!

So I have worked at a lot of places and seen a lot of different styles of programming.  Early on in my career, I became acquainted with the concept of dependency injection.  It was a hard topic to grasp, but I have learned understand it deeply.  Now, when I step into a new application that uses it, I can very quickly see the flaws in the implementation, and there's a common one I want to talk about today: global singletons.  But we'll get to that in a minute.

What is Dependency Injection?
Dependency Injection is exactly what it sounds like.  You use it to inject your dependencies. The unique part about Dependency Injection though, is that you can do this at runtime.  Now this sounds fancier than it is.  By inject we don't mean they're downloaded for you.  You still have to have all of the parts installed where you want to run your app.

Dependency Injection is somewhat of a complicated topic to a newbie.  Let's start with defining the word dependency here.  Specific…

Javascript Broke, and no one noticed

So, on Tuesday, at around 11:30, the Javascript world went into cardiac arrest.  The details are pretty interesting only if you're as deep in the code as I am, so here's a summary for the tl;dr; crowd.

What happened?
Code builds on itself.  No one (well, almost no one) codes in binary anymore because we came out with code that wraps groups of binary into smaller, more readable pieces.  That then got wrapped the same way, and so on.  That's how the software world works.  Some articles about this incident even use a Jenga tower as a reference, and that's not very far off (sadly).  This isn't just from language to language either.  Particularly in a language that's been around for a while (like Javascript), there are libraries of code within the language to do the same thing (wrap complex bits in smaller, more readable pieces).  One of those libraries has been around for a loooooooooong time and pretty much everyone relied on it, somewhere deep down the Jenga towe…