deltreey - Tumblr blog

[deltreey]

An Amazing Dream

I had an amazing dream.  For you to understand it fully will require a bit of context about me.

1. My family is crazy.  Not in a “we’re super religious way”.  Faith is a thing, but not a big thing with them.  They’re crazy in a secular way.  Most of the time, they do things to avoid doing extra work themselves.  They are bigger into metaphysics than faith.  I’m not really into metaphysics stuff.  It all feels pretty silly.

2. I spend all day in front of my computer programming.  In the background I listen to/watch a group youtubers that play Minecraft.  The series is called Hermitcraft and they call themselves the Hermits.

3. This dream may not mean to you what it meant to me.  I have only just recently began to get chills.  Unless I was sick, this was never a thing for me growing up.  They’re not cold chills, just, tiny tingly shivers all over my body.  The thing is, they only show up when I’m doing religious things: talking about God, reading a passage in the Bible, or at Church.  They’re not there all the time, but when they are there, if I take a logical look at what I’m doing, it’s something particularly deeply spiritual.

So here’s my dream.

A little boy was born in my family and I was caring for him.  He was too little to hold his head up and I was simply being silly and playng with him like you do with small children.  My family was clearly just happy to have relief from caring for him.

This is where dream logic gets weird.  It’s complicated, but I dreamed that I was unintentionally being a jerk to a bunch of people I respected all while trying to impress them with how smart I was, when ultimately I was just copying them.  It was an ugly mashup of all the things we do when we’re not thinking for ourselves and focused too much on how others see us.  (Isn’t it funny how that’s how it always works?  It’s not usually the act of trying to hurt others that causes us to do so, but simply the act of not considering others and being purely focused on what “I want”.  I find this is particularly bad when the thing that “I want” is respect and admiration)

I was genuinely worried about one such person and started saying what he was doing was evil.  I was being silly (the consequences of what we were doing had zero effect on the real world--the setting was a video game), but it was an odd thing to do.

As the video game ended I had been made to look incredibly foolish by the people I respected.  I had failed to do anything right.  I was in their way.  I was copying them instead of doing my own thing.  I never finished anything, and of course, I spent the whole time insulting them by calling them all evil.

After, I sat down in a circle with some of them and a metaphysical guru (a man) sat down with us.  He started to talk about the evil in the world.  I looked around at the others and started to analyze the situation.  I talked as I did so, saying things like “well, this person has this flaw but no, that’s not really evil”.  Then, the guru told me “It’s the one who has been surrounding this place with the word evil” and pointed at me.  I felt so inconsiderate.  How could I sit there pointing at others and calling them evil.   Of course I was being a jerk.

It was a dream, so when people make bold statements like that, everyone moves at once.  The others rushed over held me down, which wasn’t very necessary because I was just sort of waiting it out, but the guru was right.  They covered me with ash and began praying over me and it felt like he was exorcising me.  Like I said, I’m not big into the metaphysics thing, but to some extent I was like “I don’t know, maybe I am”.  After all, the things he had said were true.  I was using the word evil nonchalantly to call out other people and ignoring the flaws in myself.

My family began to surround me and join in the prayer.  At one point, my little sister came running over toward me, but I stopped her with my knees (I was laying down and my arms were held down).  She bounced off and fell onto her butt.  I felt bad, but I didn’t mean any harm (I have no idea what importance that has in the story).  As the prayer continued, the man who had started it was no longer around and I could feel myself the tiniest bit lighter.  I thought that maybe I was trying to see something where there wasn’t anything, but who knows.

As things were calming down, the little boy was handed to me again.  He was still very floppy and I held his head up.  I noticed his eyes.  His right eye was massively bulbous and staring at me.  His left eye was lazy and looking up and to the left (my right).

He spoke to me (I was impressed that an infant could do this, even in my dream brain) and said “I love you. You’re my favorite --.  You’re the best --.”  I missed some of the words, but I hugged him tightly with joy and then woke up.

When I woke up, I was filled with immense joy and knew, without a doubt, that those were God’s words to me.  I’m his favorite something.  Does it really matter what?

It was also a very clear message.  Quit focusing on what others are doing wrong and pay attention to yourself.  When you’re running around calling everyone else evil--well, you guys get the idea.

I got up and grabbed a glass of water (ask my wife, I never do that when I wake up, I suffer the dehydration instead).  As I was standing in the kitchen, and even during bits and pieces of the writing I’m doing now, I’ve had those same tingly chills.

I wasn’t sure if I should write it down.  I figured “nah, I’ll just tell her in the morning”.  When I got back into bed, my wife was dead asleep (trust me, I can tell).  The second I lifted the covers she was awake--groggy, but more awake than she usually is when she’s that far gone.

She said to me “What’s going on?”  I told her I had an amazing dream.  She said to me “Did you write it down?”  Now I have.

[deltreey]

The World is Complicated

One of the things I like to cite as proof of God is also proof of how much he loves us.  If you read through the bible, a book written about 20 centuries before indoor plumbing and over 10 centuries before sanitation was used in hospitals, it talks a lot about basic things you just need to do.

It says things like “If your house has mold in it, don’t live in until you have someone more knowledgeable than you inspect it.  It says if you have sex (something that’s famously messy) you should probably go wash up before eating dinner--especially when you’re eating finger foods with others.

I remember being taught about the incredible brilliance of God’s simple instruction not to wait for the bread to rise on passover or the Jewish people might not have made it out of Egypt in time.

I can cite these all day because, and this is the key, the bible was designed to be an instruction manual.  It was that “Hey guys and gals, this is your creator speaking.  I sort of know all the ins and outs of how your mind and body works ya know.  So uh, you might want to do these things because if you do the opposite it’s going to hurt your mind and body.”  And strangely, people resent and hate him for that.  How peculiar...

Actually, it’s easy to get angry with God.  Some people have bad things happen to them.  Jesus said it simply: (actual bible quote)“In this world, you will have trouble.”  And gave us the gift of (paraphrased bible quote)“No matter how bad you have it, know that this world is not the end.”  But that’s not good enough.

I want you to let that sink in a moment.

That’s not good enough.

Why?  It’s certainly good enough for me.  I’m not perfect, but my faith has been consistent my entire life.  But that phrase, that comment to God about his instruction manual and his clarification on how the world works is interesting.

“You’re God!  Just fix it!”  Is what is really being said.  I get that.  I understand the feeling there.  And this is what this post is about.  I want to talk about day to day life, and the imperfections that go along with it.

You get up in the morning having slept through the night.  Your fire alarm ensured that you would wake up if your house caught fire.  Your pest control service or chemicals didn’t poison you, but kept bugs from sneaking in in the night and burrowing into your brain.  Your electricity was managed by the power plant and didn’t flood into your house in unreasonable quantities damaging wires and ultimately causing said fire.  Maybe you have an alarm.  It went off loud enough to wake you, but not loud enough to damage your hearing.  If it’s your phone, it quietly charged while you slept and didn’t explode thanks to intelligent circuits inside it that charged the battery just enough, but not too much.  Your comforter kept you warm, but was manufactured in such a way that you could remove it easily if it became uncomfortable.  Your bed was soft in spite of what is probably metal springs in there, and was manufactured well so those springs didn’t come through the cushion and stab you while you slept.  Your lights work when you turn them on and thanks to good manufacturing, the switch on the wall didn’t electrocute you.  Your water works thanks to good plumbing and a myriad of city services that ensure that it gets to your home safely without being filled with toxins.  And the plumbing in your house is maintained well enough to make sure bugs or other critters don’t somehow sneak into that water during the last leg of it’s journey.  The sun rises.  The coffee maker makes coffee.  The toaster heats toast.  The fridge kept food from spoiling.  Your clothes stayed clean in your dresser.  The griddle cooks pancakes, and so on.

And that’s just waking up.  Each step along that path involves people.  If any ONE of those things went wrong, it can seem that your day was an ABSOLUTE DISASTER.  And that disaster doesn’t even require bad intent.  if somebody just did a sloppy job of inspecting the copper wire that runs through your house, your house might well be on fire in the morning when you’re awakened by a product that was well-manufactured: the fire alarm.

It’s easy to see how there are thousands of people every day responsible in some small way for your health and well being when you see things this way.  It’s a miracle that things work as well as they do.  When you question God about “fixing it”.  You’re dismissing humanity as a race of evil wasteful people.  But that’s not us at all.  99.999% of things work.  That’s a testament to how many people care, not just a little, but to the extent to make extra effort to make sure!  See, while some failures of humanity are due to genuine intent (school shootings come to mind), most of the things we blame God for don’t even require that.  They just require one person not to care enough to try.

That’s part of the reason I put such a high value on work, and how great it is.  It’s a miracle every time the toilet flushes and the pizza is delivered.  God knew about how we worked, and he gave us free will to screw things up.  So he told us ahead of time.  “By the way, there’s gonna be billions of you.  And occasionally, one of you is going to hurt the others, either by accident or by intent.  And I gave you all free will, so I’m warning you it’s going to happen.  Because I know you.  I know how you work and think.  And I love you.  So don’t be scared.  Because no matter how bad it gets, there’s more to this than what you can currently see.  The picture is bigger than that fire that destroyed your house or that person that shot your child.  The picture is bigger than the entire blue ball you live on.”

Or, as Jesus said it: “In this world you will have trouble, but take heart, I have overcome the world.”

[deltreey]

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 will sometimes disassemble and rebuild the entire engine to make it work the way he wants it to.  Your boss agrees that his way is best, because he is fast.  So you have learned to live with his way of doing it.  Sometimes it works well, sometimes it doesn't, but that's just how things go. You like working with Bob.  Your cars are done fast and you get productivity bonuses.  Bob is fun to talk to because he's so smart anyway.  But one day Bob does something different from how you're used to.  It has happened before--he'll come up with some trick to be slightly more efficient and you have to learn from it--but this time it's different.  This time, it's a big change.  On top of that, just as you're trying to figure out what changed, a new guy, Tom, joins the team.  Your manager sees potential in Tom and sticks him in your position, moving you to work on a different part of the car. Tom doesn't understand the new thing Bob is doing either.  But it's worse than that.  Bob does a LOT of unique things.  You are able to explain a few things you've learned about Bob's style with Tom on your lunch break each day, but even after several weeks he still hasn't picked up on all the different little tweaks.  Your boss is frustrated because Tom is making Bob look bad by slowing down the completion of his cars, and lowering the quality as well. Tom even figures out the new big thing that Bob did, but he's struggling a lot.  Just as he gets into the swing of things, Bob changes something again.  The manager gets fed up and puts you back in place of Tom.  You have spent weeks doing things the normal way and have forgotten many of the tricks that you're used to doing with Bob.  It takes you some time to get back into the swing of things.  Moreover, you never learned about the big thing that Bob had changed before you left, let alone all the other new tweaks he's made since you changed roles. You try and get a rundown from Tom, but he's not really great at explaining things.  His skill is with cars, not people.  You are at a loss and you struggle for several weeks as well.  Overall, the factory loses months of productivity before one of you figures Bob out enough to get caught up. Now, imagine that's software development. Because it is. Don't be Bob. Document your changes.  Work to fit existing patterns of the team.  Agree on big changes so EVERYONE benefits from efficiency increases. If Bob rebuilt the alternator, he needs to remember to keep the mounting brackets in the same place so it still fits in the car.  This is contract programming.  Keep your inputs and outputs the same even as you improve things in individual functions.  Use inputs and outputs rather than events so that your code can be followed and understood easily.

[deltreey]

Working Hard

Let's talk about hard work.  A fascinating thing is happening in the world today.  Work, and everything involved with work has become the enemy.  Retire early.  Work less.  Higher pay for fewer hours.

I get it.  When I'm 60 I don't want to be working construction to pay the bills.  I want to have enough money to have options.  But to not work at all?  That's strange to me.

But it's not just strange to me.  The people who talk about working less say the same thing.  What kind of retirement would it be if you had absolutely nothing to do. That's not living.  That's just dying slowly.

And that's the real truth.  In the first world you can retire with nothing and still survive.  But retirement isn't about doing nothing.  It's about doing everything.  You retire wealthy so you can do more, not less.  And for that goal, you work hard while you're young... because you want to work hard when you're older at things that mean a lot to you.

So why are we opposed to working hard in our youth? This image articulates the way I've heard it phrased a lot lately.

I can argue about this all day but that's not going to change how often it's perceived as true. I know 90+ year old men who run marathons. I know adults who are so deep in student loan debt that they can't afford to move out of their parents' house. I know children with more money than their parents.

This image is designed to defeat us. It's designed to tell us: there's no point. If we truly believe this BS, we're encouraged to take out massive debt when we're young and save the work for later. But that's not how it works.

Debt is a limitation. It restricts us. It binds us. This image encourages a world of old ladies in work camps on chain gangs. But that's not even my problem with it.

It calls work a waste of time. What?!? Why is working not a great use of your time. When you work you're creating for the world. Work is how we show God how much we appreciate this amazing creation he's given us and show him we're not going to squander it.

Work is called making money, but maybe it should just be called making. When you work--I mean honest hard work-- you're being paid because you're making something people need. Maybe that thing is a cheeseburger or a line of code, or maybe it's more abstract like financial advice or connecting people with needs to products (sales).

So I'm a member of the maker movement, building micro electronics for fun. I've always felt that is what the maker movement really was about. Working. You can't make things without hard work, and who wants to live a life where they never make anything?

Then it hit me. The people who made this diagram. The people who shun work. They're not misinformed. They know exactly what they're saying. They're just mooches. They don't want to work for what they have. They just want everything given to them.

The problem with mooches is that time when they have stuff and no longer need to beg for it. They have no skills. They're not even very good at wanting things. They're afraid. Afraid of all that time. They think they'll finally have time to do what they want when they're old. They just haven't realized that what they want is not to do.

They think that money equals time. It doesn't. Money equals options and options are paralyzing. You spend all those years of your life working not just to glorify God but also to learn what you really want. You need that skill so that once you have all those options you can act and do amazing things.That's why some 90 year olds run marathons and some sit in front of the TV watching the same reruns they have for 30 years.

You need to work to build the understanding of who you are and what you really want out of life. You need to work hard now so you can work hard later. Because that trip around the world, that lake house in Vermont, those round trip flights to see your grand kids. Those are definitely going to be a lot of work.

[deltreey]

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 worker.  But they are employees, which means they must be managed too.  Software development is brain work.  Everyone says this, but no one acknowledges what it means.  Maybe I can get the point across with and example. I was working my first .NET job years ago, and I was still learning how to code .NET.  I was capable of coding other things, but I was still getting a grasp on the complexities of the Visual Studio IDE, something that takes months to years depending on the developer.  A random manager (not the development manager) came up to me and asked me to create a bunch of folders on a shared drive.  He sent me an excel spreadsheet with over 1k folder names.  I pondered how to do it and gave him an estimate of 5 hours as I tried to figure out how to write a program to manage file systems in .NET.  I started creating a complex application and learning about how the code could be used to manipulate the folders and how to import the list of folder-names from excel.  After an hour, the development manager called me over and showed me how dumb I was being.  He showed me a quick Excel trick (that I knew) to add extra columns with other content, (specifically the mkdir command from the windows command line) then copy pasted it into a command prompt and pressed enter.  I immediately used his idea for the larger list and had the project completed in 5 minutes. Developers are tasked with jobs that other people don't know how to do.  There are usually 100 ways to do the task.  It's not just the developer's job to do the task, but to find the most efficient way to do it.  But if you think about what that means, something else may occur to you, something that every developer knows, even if they don't admit it to themselves.  If you don't know how someone does something, how can you know where the limits of their capabilities end?  Developers are often given tasks that have nothing to do with software development.  In the example above, I could have simply spent 5 hours creating the folders by hand.  It's not really software development, but the manager didn't know what is and what isn't included in that list.  A knowledge worker's job is to get it done.  Programming is a side-note to developers today.  Our job is just "whatever it takes".

How do you keep them working?

I talked about this at length in my previous post on Managing Developers.  The truth is that your programmers took the job because they love it.  But motivation is a genuine problem with all employees.  The answer to this is (surprisingly) found in the daily scrum.  I don't advise that all of Agile is needed for every org.  But the morning meeting where developers talk to other developers about what they're doing is really everything you need to provide them with motivation.  They will see when they're slow, and have help from others in moving quicker. But as managers know, every person is unique.  Many blogs suggest varying degrees of balance between pay and making the work interesting.  But the truth is, your best developers will be working on code, even if they're not working on your code.  Getting them to work on your code is matter of making your code something interesting to do, which a lot of companies get.  But there's a second factor there that a lot of people forget as well.  We'll get to that in a bit.

How they screw themselves

Developers make crappy managers.  This isn't new information.  In fact, in software development, to tell another developer "you would make a good manager" is an insult.  It means "get out of my code, you're breaking it".  Because developers make crappy managers, they don't often take on the role.  More importantly, when they do, they do a bad job of that.  Managing people is a complete 180 turn on how they did their job as a knowledge worker.  As a knowledge worker, they had to "get it done" regardless.  As a manager, their role becomes "what is reasonable to get done" and "what can I be certain of"? What's worse is that estimating is hard.  As I said above, software development is about getting any task done, even if you're not sure how to do it.  How do you estimate how long it will take to do a task that you've never done before?  You don't--not well at least.  At the good software companies, at least they let the developers do the estimating (at the bad ones, their managers try to estimate for them), but that's not really a solution to every task being unique and new. Unfortunately, while it's hard for developers to estimate, it's even harder for them to estimate their own skill level.  I couldn't count the number of developers whose response to every task is "sure, I can do that".  Maybe some of you can, but a minor argument could mean the difference between six years and six weeks.  This would be a manager's job normally, but those managers were often developers before.  So their default response is also "sure, we can do that". And the hardest part to understand here is that the "sure, I can do that mentality" isn't wrong.  As I said above, that's what a knowledge worker's job is.  But when you transition into the role of managing people, your job is to make decisions, not to simply follow instructions.  What tends to happen is the opposite.  Developers either managing themselves or managing other developers just keep saying "yes I can" instead of "do you think that's a good idea?".  They are perpetually, and consistently overworked.  Actually, that's not true.  Some of them are perpetually and consistently overworked.  These guys burn out and quit.  The others are perpetually and consistently under-performing, often intentionally to avoid ending up like the other group.  There is very little middle ground. That dichotomy has created an interesting stereotype.  Developers are considered lazy.  Their estimates are considered over-generous.  And they're usually given even more work and complained to about how long it's taken.  I like to refer to Software Development as magic (which I take directly from SCIP @ MIT).  The problem with magic is that it is simultaneously impossible and instantaneous.  So developers often see their co-workers simultaneously mesmerized by their work and complaining that it took too long.  That's not a reasonable situation in any other profession.

So how do you manage that?

The good managers have learned that managing up is often more important in software development than managing down.  As I said, the good developers want to be there.  But note that I'm also only talking about the good ones.  Because many developers have worked other places and seen other developers burn out, they may already have bad habits and find ways to reduce their workload.

attribution: Dilbert

The reality is more akin to the Scotty Principle than you might think, and there's a reason for that.  It's not about you.  It's not about reducing the work-load.  It's not even about keeping your boss in line.  It's about your company!  The cost of software is astronomical.  It's goal is to make your company money (or save your company money, but the result is the same from an accounting perspective).  And as we have seen, software estimates are basically bullshit, so if you trust them, you're going to have delays with releasing the software. And that's the core of it.  Unexpected delays cost money--a lot of money.  If you release software early, no one gets hurt.  If you release it late, often millions of dollars are lost.  It is vital that software estimates be inflated, not for the overworked team members, not for the slackers, not even because it makes you look good to release early.  It matters because the estimates will be wrong and that costs your company money. Here's an example: You tell your company (or customer) that it will take you 6 months to implement something.  You deliver it in 3 months.  The staff has been retrained in another month, and you have a better company for it.  Imagine if you had said 2 months?  Staff training taking a month, the company would have started retraining 1 month into the project.  Retraining would be complete a full month before the project was finished.  The staff training might stick, or it might not.  The new machines they brought in to run the project would be sitting gathering dust, and the contract they had cancelled had to be unexpectedly renewed for astronomical costs--and that's just for starters. Because the project is behind, you're pushed to release it in an incomplete state.  Your developers are overworked and the end result is not as good as it would have been.  To clean up the code and get it working right with all the original intended functionality is likely to actually end up taking the full 6 months in that situation.  It's incredible.

Why would you do that?

This all sounds like you're going to end up being the manager who gets fired for stuff taking too long.  And there will be people who claim they can do it faster, but that's corporate politics and is well outside the scope of this blog post.  Here's the reality.  Trust is everything in management.  You're in charge of people because the company trusts you to have their best interests at heart.  If you betray that trust by failing to deliver on time, then you are not strengthening your position. Trust is even more of a big deal in software development.  I often get jokes from charities I help out with IT services about how "I don't mess with you because I like my money in my bank account".  And that's a real thing in enterprise development.  Not just from the perspective of trusting programmers to correctly handle tons of PII data about you and your employees and customers, but also because the programmers don't have to be malicious to cost you money. Since the role of managing software development is more trust-inflated than even that of other managers, you need to be that much more reliable.  If you make a mistake, the costs can literally be every dollar in the bank.  Do not take that responsibility lightly.  More importantly, don't shrug it off to get a slightly better estimate.  Take your time.  Get it right.  This is a scientific game, not a productivity one.

But nothing will get done!

This is where things get interesting.  We have seen companies (like Valve) where their programmers never complete a project.  This is a very real possibility if you only manage up.  If you only ever inflate estimates and keep telling the upper management "no".  But that's only half of managing programmers.  What I've described so far is all about managing their estimates.  The second part of this discussion is about managing the work. Everything I have to say about this can be summarized in one sentence.  Don't lose focus.  Software Developers (especially the good ones) love to explore every new technology, try every new thing, and learn every new language.  At every meeting with them, you can expect them to suggest using this technology or that to make the project better.  New things excite them. Other managers, similarly, love exploring new ideas.  New sales ideas, new software to increase productivity.  New technology that will automate more of the business.  These ideas align perfectly.  The result is that the managers and programmers feed off of each other talking about how they can leverage this new technology to provide this new software.  It is a wonderful experience being in a meeting of dreamers like that.  The problem, of course, is that dreamers aren't always doers. Dream big.  Let your developers dream big.  But you set the timeline.  You set the agenda.  And you make sure they finish a project before moving onto the next.  Managers will often want to pull people off of your current project to start on another.  Push back!  If your company is worth the money they pay you, then it's important work!  A manager pulling a programmer off of one project--even one the developer is excited about--is just as dangerous as changing your technology stack halfway through a project.  And it happens ALL THE TIME. Work will progress just fine, as long as you don't let your programmers lose focus, either from their own hubris (I can implement this new thing in no time) or from the company's eagerness to try new things.

And...Magic!

Something magical happens when these things align.  Your developers find they don't have to pretend not to work hard.  Your managers don't have unrealistic expectations.  Your company makes money, and progress moves forward--at a reasonable, but not breakneck pace. Something even more terrifyingly magical happens when they don't.  I've seen this, so this is actually happening.  There are companies that no longer hire their internal software developers to do things.  They hire outside contractors because their internal developers give them timelines that can literally be 10 years for a single page website with no major functionality. That is not how a manager conflates timelines.  That is how a developer does.  This is a place where the developers have learned that no amount of time is enough.  So they come up with arbitrarily high numbers because they don't want to be wrong anymore. So understand how important it is for you to get it right.  Because if you don't they'll find another way to survive, and it will look like that, or worse...and yes, I've seen worse too.

[deltreey]

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 the credit cards process correctly then it's done, it's working.  But even in that simple example you can see how modern society doesn't end there.  There's constantly changing regulations on how the card has to be processed.  There's new security features like chips that we need to handle as they come out.  Different companies will change the way they format the data in their magnetic strips.  And that's not to mention the fact that there's always new and different banks and credit card companies that you'll need to deal with.

But that's really the problem isn't it?  We perceive done software as this never changing stone that can do absolutely anything.  The reality is, it does one thing--what it was programmed to do.  The world around the software is ever changing.  When new software comes out to make searching for information easier (aka Google),  we begin to rely on that and we want software that can make our company appear at the top of relevant search results.  The world around us is not static.  Software is.  For that reason, it's hard to make software that is done in a world that isn't.

But software really can be done

Software that does it's job well enough might never need changing.  A great example is a 1980s computer still running HVAC at some schools.  There are hundreds of similar systems out there.  Examples of done software can include things like the pipe command in linux, or the dir command on windows.  This software hasn't had a need to change in a long long time.  And there's a reason for that.

Software that only needs to do one thing can be done

If you can clearly and completely define a single thing that the software needs to do, it will be finished.  The important part of that sentence is completely, because "process credit cards" is not the full definition.  There's reading magnetic strips and chip data.  There's encryption and decryption.  There's integrating with varying credit card companies.  There's keeping up with industry regulations.  And note that each of those things are not complete definitions either.  Chips and strips have varying data formats that change by company.  Encryption and decryption change every other week as someone finds new ways to make things more or less secure.  "varying" credit card companies is it's own bag of wax.  And regulations don't even have a reliable way to be discovered by lawyers, let alone a software developer.

Integration is a dirty word

The biggest problem with the concept of done software is more subtle than it seems.  Integration.  Integrating your software with someone else's software makes the two pieces of software into one piece of software from the done perspective.  If your software is done, and they change theirs, then your integration fails and you have to change it.  So, the second you want to integrate, you introduce a huge exponential factor that makes finishing your software harder.

Changes bite hard

Even then, if you think about this in terms of two simple pieces of software this is understandable.  But the second your software is something complicated that won't be done anytime soon (like credit card processing tools) then you create a scenario where your integration can't be complete until the rest of your software is.

But that's not even the worst of it.  The worst part comes back to what it means to be finished.  Software that you start working on before it is completely defined will take longer to finish than it would otherwise.  And this is not what most CEOs want to hear.  In manufacturing, the sooner you start on a product, the sooner it's finished.  In software this isn't always the case.  If you change your mind halfway through, you can completely change the way the software needs to be written.

More often than you might think, what appears to be a subtle change can be nearly impossible for software that was built with certain conditions in mind.  A common comparison in the software world is a house.  If the customer says "we're going to live in Florida" then the house designer might do things like lower the roof angle since snow won't be a problem but hurricanes are, and replace the frame with hardier wooden beams to resist the extra moisture in the air.  If the customer makes no other changes to the design except deciding to live in New York instead, the frame and roof, and various other bits, have to be completely changed.  And those changes result in a very different house in the end.

I can't tell you how many meetings I've been in where software developers, seeing the dangers of change, try to get clarification by asking something like "What if the user has two middle names?" only to be dismissed by management with "That'll never happen".  Then, having structured the database and apis around this particular situation never happening, they have to account for it at a later date when "never" turns out to be "rarely".  I always advise my co-workers to be careful about these situations.

Realistically, you don't usually want done software

In the end, done is not what we really need.  What we need is functioning software.  If it works for the moment, we can let the developers keep working away at fixing it, improving it, and adding more features and integrations as we need them.  This is why Agile is so popular in software development these days.  Most companies have accepted that diving into having their own software developers is not a temporary investment.  They are going to keep them around forever as the company's needs grow and change.  Because the world is changing, so the software must also.

Take my recent release as an example.  This software is functioning, and it's doing so well.  It's brilliantly effective at doing it's job, but it's job is complicated and ever-changing.  The mortgage industry is inundated with ever-changing regulations, and we're working our way through dozens of integrations at the moment.  So we'll continue to work on improving and integrating this software for years to come, but it works!  It's out there!  And it's ready for your company to use NOW!

And that is a wonderful feeling.

[deltreey]

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 goes something like this (yes, with this many steps, Yay TCP!).

Your Computer - "Hey bank, I'd like to see your login page" Bank Computer - "Sure thing, here it is" Your Computer - "What is this gibberish?  Must be encrypted.  Hey bank, I'd like to see your encrypted login page." Bank Computer - "Sure thing, here's the encrypted login page and translation instructions."

It's all a sham

SSL/TLS encryption is the fancy term to refer to this method of security today.  The problem is subtle--or more specifically, subtlety.  The problem is this:

You see, the only way to know if a website is secure today is for you, the user, to see that green little https lock icon.  There's no check to ensure that you don't accidentally log in on a page that looks like this:

The difference between the former and the latter from your perspective is whether or not you were paying close enough attention, which even many security experts fail to do.  The difference in terms of security, however, is everything.

Modern browsers don't manage this for you at all.  In fact, security experts got caught recently by a fake google site, and the only difference was the above text.  And of course, the other side can be true too.  http://google.com is not safe, but so is http://ift.tt/2b3JzPR because users can bring you to sites with the wrong URL just as easily as one that isn't secure.

The problem is sharing

Programmers attempted to build security around https into browsers to let you know when a website was unsafe, but there's no way to know which websites should be using encryption and which shouldn't, so instead they chose to check if the encryption of the website did indeed come from that website--which they only do when there is any encryption at all in place.

This is where you get gigantic warning pages about websites:

The way they know that http://ift.tt/1IVTtxu should be red and https://google.com should be green is called a Certificate Authority, often called a CA.  Because the programmers who wrote your browser can't possibly know every website that should have https, they rely on the website to tell your computer, as in the above dialogue (handshake).  When you get back those translation instructions (called the certificate) from the website, the browser then goes to a CA it knows and trusts to see if that really is the correct instructions for that website, because if it's not, you're just encrypting the data to send it to someone who's pretending to be the website, which would defeat the purpose.

If the CA hasn't heard of the certificate, the browser gives the gigantic warning page above, which makes you feel very safe.  But remember, that if they don't even bother to encrypt the page, there's no warning at all, even if it's a page that's usually encrypted.  Because CAs are the only accepted authority on what sites should have what certificates, they have to be right, every time.  For this reason, and the costs associated with that, CAs have always charged a decent amount of money (hundreds of dollars per year on the low end) to grant your website a certificate that they will tell the browser is safe.

You can create your own certificates (translations) for your websites, called self-signed certificates, but your users will get this gigantic warning page every time they try to go to your site unless they do some manual configuration to accept the certificate on their computer.  This is why most websites don't even bother to encrypt.  It costs too much, and if you do it yourself, browsers actually make the experience worse for your users than if you didn't do anything at all.

Enter Let's Encrypt

The world of CAs is going a little nuts right now, as a newcomer to the market has decided to issue certificates for free, and completely automate the process.  What's unusual is that, the newcomer is actually being accepted by all major browsers.  This is incredible.  Now, people who make websites can encrypt them just for fun!  There's no longer any reason not to see that beautiful green https at the top of your browser.  It doesn't cost anything!

Now, I may not sound like it, but I'm usually quite skeptical of new technology.  I like to use it and study it, but I don't usually trust it in production until it's more tried and true.  Let's Encrypt still acts like new technology.  It's unwieldy and hard to use, but it works, and because I care about security it's worth it to me.  From the perspective of someone who doesn't like it when things are hard, however, here's a StackOverflow post I wrote about issues with setting it up.  It's not everything, but it has some links that should help you along the way.

What's great about Let's Encrypt being free is that everyone should be doing it now.  If you make websites, encrypt them.  I don't care if it's just a blog about baking cookies, or a picture page with no logins.  Encrypt it!  You see, since programmers never could figure out a good way to identify whether a website should have a certificate, we can create an internet for them where they don't have to.  If every legitimate website is encrypted, then they can tell the browsers to throw ugly scary warning pages when there is no encryption, and take that onus off of the user.

This means a lot to me, as a programmer who understands how important your personal information is.  The internet is dangerous, and this is one way that we can make it just a little bit safer.

Encrypt all the things!

[deltreey]

Faith - It’s not like that

I’m not dumb.  Let’s start from that premise because it’s important.  A lot of die-hard atheists have this impression that everyone who believes in God is simply retarded, and that is far from the truth.  This post isn’t about that, but let me put it this way: if you do your research, the majority of the people at the very top of their fields in pretty much every industry have faith, at least admitting to being agnostic.  It’s the wannabes that are die-hard atheists.

Let me be clear.  I have a very scientific mind, and it has taught me to question everything.  So when science tells me that evolution is a thing, I ask for proof, which there is an abundance of believe it or not.  Did you know you can physically watch organisms evolve in a petri dish?  If you look around at the universe (you can, it’s right above you), you can see the amazing beauty out there and know that it’s more complex than we can imagine.  The way I see it, God put all these things there for us to study and try to understand, so I respect science as furthering God’s work.

But it’s more than that.  I don’t just see God in the universe around me, but in the actions that people take.  It’s not just what science is discovering about the universe that’s so amazing, but it’s that they’re discovering it, and how they’re discovering it.  Take a look at amazing creations like skyscrapers, rockets, supercolliders, nuclear power plants, and so much more.  What do you see?  I see God there.

This post isn’t about that though.  I can gush forever about all the amazing things out there, but that only serves to encourage a bit of wonder.  Instead, I’d like to talk about something that a lot of people, both those of faith and those without, get wrong about God.  And the funny part is, if you don’t care, or entirely disagree, that’s OK with me, because I see God in you, even in your bad decisions--and that’s what this post is about.

Trust is like watching an acrobat walk a wheelbarrow across a tight rope and knowing that he’ll get to the other side.  Faith is getting in the wheelbarrow.

A friend of mine said this recently, and it is sort of the premise of this discussion.  I’ve been binge-watching House on Netflix recently, and I saw an episode about a priest.  Now a lot of the episodes of House are about his battle to stay atheist as many around him see reasons to believe, but this was an interesting episode because the writers got it wrong--or, more specifically, the character got it wrong.

The short version is: an ex-priest lost his faith over the years as his life turned bad when an altar boy falsely accused him of molesting him.  He admits himself to the hospital after hallucinating a vision of Jesus.  Over the course of the episode the altar boy comes and apologizes and mostly his life takes a massive turn-around.  In the end House has to write-off the hallucination as one of the symptoms of his illness, and the priest regains his faith.

This is where I see brokenness in how people perceive faith.  Many people who’ve fallen on hard times say that they have “faith that things will get better”.  This is flawed.  Faith isn’t about the future.  Faith is about now.  Faith is not about your life getting better or worse.  Faith is about your life going as God planned for it to go.  Faith is about trusting that, whatever happens, it’s what God wanted to happen.

You can trust that God wants your life to get better, but that’s not how it works.  God wants the universe to be a better place.  You’re just a tiny part of that.  If you need to suffer, even for your entire life for that to happen, then that’s his plan.  It may suck, but faith isn’t about your life being great, it’s about everyone else.

This is where people tend to get silly.  They think I’m saying that God wants babies to die, war, rape, and suffering to happen, et cetera.  So while my premise for my counter-argument to that is simple: God is smarter than you, it bears explanation.

There are other factors at play that make all arguments about the horrible things that happen less valid.  The first of which is free will.  Having free will is what makes having faith necessary.  Without free will, it’s easy to argue that we cannot make any decisions, allowing God’s plan to work every time.  The truly magical gift that God has given us is the ability to make decisions for ourselves.  And the faith I have is that, in spite of all of our free will, and in spite of all the dumb things we do with it, God will make it all work out--in the end.

I like to think of God as a chess player, where every single piece is moving of its own accord and all he can do is set up the board initially and hope that the pieces go the right direction--and that’s the most amazing thing.  He doesn’t hope, he knows.

He knows that if the earth is formed just right, there will be a rock in just the right place so that you’ll step on it and slip slightly, so that you’re paying more attention and don’t get hit by a bus in the street, so that you can later have kids, so that one of those kids can grow up to become a writer, so that his writing will be have a meaningful impact on someone else entirely who has to make the decision to stop something evil from happening, and reflects on that book to make their decision...And all of that, on a much larger scale than even I’m describing, because we’re talking about doing that at a universal level--the positions of comets not just to what they hit, but who can see them and be moved by their beauty.  It’s truly humbling to think about.

If you think of God in the more physical sense, you might consider him as simply a super-intelligent being capable of creating life.  But what makes God good?  It’s simple.  He doesn’t destroy us.  He has the power to create life, and in spite of what that life chooses to do with itself, he gave up the ability to destroy it.  He understands that life is precious, even if he can control it.

Could you imagine us being that generous?  We’re far from it.  We create life all the time and destroy it when it becomes dangerous to us.  I’m speaking mostly of bacteria and the CDC doing disease testing, but there are other examples, like pruning trees, and reducing the numbers of certain species through hunting intentionally to keep the ecosystem in balance.

God has given us a simple principle to define good over evil:  The power to create life does not give you the power to destroy it.  It’s something that, someday, when we’re strong enough and wise enough as a species, perhaps we’ll be able to emulate.

But he’s gone one step further.  He has not only chosen not to destroy us, but he gave us free will.  He has granted us complete autonomy to do as we wish and never forces us to go the way he wants us to.  It’d be like all of the cattle farms on the planet having no fences, or all the wheat farms in the world being allowed to pollinate and spread naturally instead of planting them in organized patterns that allow us to harvest them efficiently.

Can you imagine having such a level of intelligence and wisdom as to be able to let the entire universe act on its own and knowing how it’s going to end?  The universe is complicated, but I suspect that’s another tool in God’s arsenal.  Maybe it’s complicated to encourage us to explore it.  Maybe he wanted us to always feel small so we’d remember that his plan is bigger than any one person can ever be.  That way we make decisions that make the universe a better place and it all turns out the way it’s supposed to in the end.

It’s about faith, after all.

* This is just a small piece of this discussion, and I want to make that clear.  Because I’m smart, I can’t dump my entire brain into this post which has already become quite long.  For example, think about how God’s decision to make the universe a better place must have also taken into account how you would feel and think, and how he made an effort to fix as much of your life as he could without completely botching the equation.

** It’s also important to note that I’m a firm believer in “God helps those who help themselves” because he would have to find some way to encourage us to make progress, and so rewarding good decisions would have to be built into his math.

***  I use “he” here to refer to God because it got repetitive and hard to read and it’s the common vernacular.  I don’t imagine God identifies with a gender.

[deltreey]

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 knowledgeable about the code in question (that may be yourself) when you encounter a code smell is "Why does it smell?".  This is the part I see skipped--A LOT.  This is the most important part of the process.  Let's face it.  There are legitimate reasons for things to smell.  Your mechanic's shop should not smell the same as a bank vault!  Each code base is going to have its own set of smells, and that's ok, as long as the answer to "Why does it smell?" is reasonable. In a project I've stepped into, singletons are everywhere.  I asked one of the developers about them and his answer was one sentence.  "We have memory constraints."  Oh!  That makes sense.  This application lives on (crappy) webservice connections, and is written in an older language, so it's logical to store those connection objects for reuse later, rather than waiting on a crappy garbage collector to delete them and running out of memory.  This code base smells like they're using singletons as global objects.. Guess what?  They are!  And it's OK.  That was their intent! Of course, the answer is not always valid.  If the answer is "That's the way it's done" or something else vague like that, it's time to investigate yourself.  It may be that there is a legitimate reason and you haven't encountered it yet, but this is a code smell, and so you need to find the source.  You cannot, and should not go changing code to "fix the smell" if you don't know why it smells. In my example, if I had started getting rid of singletons to "fix it" and making them instances of the service all throughout the application, I would have surely crashed production!  Don't go fixing things that you don't KNOW are broken.  Code smells are just that: a smell.  Some smells are supposed to happen!

What if it's bad?

So you've identified a code smell.  You asked "Why does it smell?" and you figured out, through some form of investigation, that it's bad.  This is the smell of burning rubber over a box of wires.  It's a bad smell, we need to fix it. You're not supposed to fix the smell! So many developers get this bit wrong.  The smell is your marker.  It identifies that there's a problem in your code base.  The smell itself is NOT the problem!  99% of code smells are pointers to an architectural problem!  The smell "goes away" when you fix the root problem.  Saying "x is a code smell" is not the same as saying "x is bad".  The code you're looking at solved a problem.  It is good code.  It just may not need to exist if you fix the part of the code that is bad.  The part that caused the smell to begin with. As an example, in my current day job, they identified the singletons but knew that "singletons are a code smell".  They made the standard mistake.  They think that the word code smell means "bad".  So they say "singletons are bad".   Then they try to remove the singleton.  This actually happened in this code base.  They did something I'm seeing a lot on blogs.  They wrapped their singletons in a Dependency Injection library and pretended that, since the instance is being passed to their class via dependency injection, it's no longer a singleton.

Don't hide the smell!

Ok, so the new guy is just starting.  He didn't do any of the above, but he saw the singleton pattern and got all excited to help and swapped it out for dependency injection...  What did he do?  He masked the smell.  The smell is there for a reason.  It's like covering up the dog turd in the middle of the floor by putting a towel over it.  Whether this is a kennel, where that dog turd needs to be kept in the dog-turd specific area (maybe a singleton resolver class or some such), or a perfume store, where it needs to be cleared out immediately at all costs, he has made it harder to fix, and hard to identify for everyone. In a code-base where the smell identifies an actual problem, to fix the smell masks the real problem and keeps you from finding it longer. In a code-base where the smell points to outside forces beyond our control, the fix makes it harder to maintain, and harder for new developers to step in and learn about the code base. Never, ever hide the smell.

What about your singleton problem?

With a big problem in an existing code-base like this, I'm starting small.  First thing to do, unmask all the singletons.  I'm creating a group of static classes that wrap up the singletons in the application.  Some day in the future, I'll be able to remove the Dependency Injection framework entirely and start over, using it correctly (for actual dependency injection).  But until then, I've had to think differently.  For now, in this particular code-base, whenever I see that dependency injection is being used.  That, for me, is a code smell.

[deltreey]

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.  Specifically, DI is about classes, but everyone who talks about DI talks about Interfaces.  This is because DI does something unique among software patterns.  It doesn't decrease the amount of code you have to write, it increases it.  That's right, when you start using Dependency Injection, you can expect to write a lot more code, a third as much as you are currently writing or more (beyond 100%) on top of your existing workload.  For every class you write, you need to write a matching interface that provides access to all of the class's public properties, and the class needs to implement that interface.

Then Why Use It?

Like all software patterns, DI is about making your code easier to work with.  The magic of DI is the interface.  Interfaces are simple stubs of classes that essentially mean "any class that implements this interface must have these public properties".  That's it.  It's a set of rules for creating a class.  This makes it easier to write your class later, because you know it only needs public properties X, Y, and Z.  Let's look at a real life example.  I'm pulling this example from a library written by a good friend of mine who's worked with me at some of my big name jobs.  Here's the full library for reference: http://ift.tt/1oJPTzp First, let's look at an interface he created for storing data.

namespace Squire.Storage { using System; using System.Collections.Generic; using System.IO; using System.Linq; using System.Text; using System.Threading.Tasks; public interface IBlob : IBlobItem { void SetPermissions(BlobPermissions permissions); void Delete(); void PerformRead(Action<Stream> readerActivity); void PerformWrite(Action<Stream> writerActivity); void CopyTo(IBlobContainer container, string copyName = ""); } }

Pretty simple right?  Basically his interface offers CRUD.  Create, Read, Update, Delete, and a few other minor features.  OK, it's not perfect CRUD, but I'm sure he intended for it to be that way. If you've written code for storage, you can imagine how having this template makes it a little easier to write the class that implements IBlob, but the value of this interface is the ability to use it for Dependency Injection.  Let's take a look at another Interface (because they're short) that uses the IBlob interface as if it were an object.

namespace Squire.Storage { using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; public interface IBlobContainer : IBlobItem { IBlob GetBlob(string name); void CreateIfNotExists(); void SetPermissions(BlobContainerPermissions permissions); IBlobContainer GetContainer(string containerName); void Delete(); IEnumerable<IBlob> SearchBlobs(string filter, bool recursive = false); IEnumerable<IBlobContainer> SearchContainers(string filter, bool recursive = false); IEnumerable<IBlobItem> Search(string filter, bool recursive = false); IEnumerable<IBlobItem> Contents { get; } } }

So we can create objects and refer to the types by the interface instead of by the class.  But ultimately, an interface is not a class.  You cannot create an instance of an interface.  You can only create an instance of a class.  What we get is a state where you can rely on any class that implements your interface to have those same public properties.  They call this a Contract.

Wait, this is about inheritance?

No.  This is where we talk about the second thing people talk about with Dependency Injection: Inversion of Control.  The benefit of having these interfaces is that you no longer have to worry about HOW something will be implemented.  You can pass off individual classes even between developers and they no longer have to know what each other are doing.  They have an interface that binds them.  That interface tells you in a very concise way what the architecture, the structure of your application is.  The individual class implementations can be good or bad, but you don't have to know how one class works in order to work with another.  Instead, you only need to know what public properties that class will provide you, and you can build your logic around it. Inversion of Control is where you decide which class to inject at runtime.  You get control of your implementation at runtime, instead of at compile time.  Your control is "inverted" from the traditional implementation..  If you think about a traditional implementation of the above interfaces, BlobContainer would have an instance of Blob.  Which means that if you change Blob, you can easily break BlobContainer.  But if BlobContainer relies on an IBlob interface, then you can change Blob all day.  As long as it implements IBlob, BlobContainer will be unaffected by those changes. BlobContainer now has control over the contract it chooses to support with objects that implement IBlob, rather than the other way around. This is what Dependency Injection gives us.  It creates a clear application structure that we can rely on.  But it has a bonus feature.  Interfaces can be implemented by multiple classes.  Since we can swap out these classes at runtime, which means: we can swap out our implementation.  For this reason, if you're working in a statically typed language, you should always use this Interface pattern.  In fact, that pattern has been around a while.  It's called the Revealing Interface Pattern, and has varying names and slightly modified versions in many languages, even those that are not statically typed.

So what's wrong?

Because you can change your implementation at runtime, you can do some crazy things.  The craziest I have seen is that some people use their DI library to create "global singletons" that they can access throughout their application.  Globals are bad.  Singletons are bad because people treat them like globals.  Wrapping singletons in a Dependency Injection library adds extra weight.  To add that extra weight in order to do something that's bad in the first place is so dumb. Use Interfaces to make your code easier to follow, and IoC in order to make it easier to change out dependencies (read: classes).  Don't use DI to make your dependencies global.  Dependency Injection: You're doing it wrong.

[deltreey]

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 tower (we call it the software stack).  For the devs in my audience, some of the software that directly relied on left-pad (the library that was the most important here) included Node.js and Babel.  For the non-devs: it was pretty deep down the stack--so deep that most people weren't even aware they were relying on it. Azer Koçulu is the man of the hour.  He built the tiny piece of code (literally 11 lines) that everyone was using.  He was responsible for hundreds of emergency meetings on Tuesday (I don't know the exact number, but you can imagine a lot of execs calling their IT department screaming).  He's a big deal in the OSS (open source software) community.  He's published over 250 packages to npm, the place most people (including Node.js and Babel) get their Javascript code.  On Tuesday he un-published all 250 of his packages, including one innocuous 11 line piece of code called left-pad.  After that moment, everyone whose code relied on left-pad at some level was fine (really, it was).  But new code starting out, and deployment builds all failed, because they couldn't retrieve one little dependency.

Why did he do it?

I'm not going to steal the man's thunder.  He published a blog post in his own words saying why he did it.  Here's the tl;dr; version. Koçulu had a package named kik.  A messenger company named kik asked Koçulu to give them the package name so they could use it instead.  Koçulu refused.  The company pleaded with npm.  npm sided with kik.  Koçulu was offended and decided not to be involved with npm in the future. It's a bit more complicated than that: Koçulu was good friends with most of the npm team, including the guy who took away his package.  kik sent Koçulu threatening emails, and Koçulu sent kik rude emails.  The whole thing took just under 3 weeks to come to this. For some perspective, here are some of the highlights from the email chain, which was published by the kik team in their own blog post on the matter. kik:

our trademark lawyers are going to be banging on your door and taking down your accounts and stuff like that

Azer:

fuck you. don’t e-mail me back.

kik:

Is there something we could do for you in compensation to get you to change the name?

Azer:

you can buy it for $30.000 for the hassle of giving up with my pet project for bunch of corporate dicks

What I expected

While Koçulu was kind of a dick to kik, and kik was kind of a dick to Koçulu, all of that was more or less expected as far as I'm concerned.  Open source developers, especially those as active as Azer are notoriously anti-establishment and are likely to respond to even gentle requests from them harshly.  And kik has trademark rights to consider, so you expect them not to be nice when someone tells them no.  They actually mentioned it in the email chain: kik:

we’d have no choice but to do all that because you have to enforce trademarks or you lose them.

All of that is more or less, the sort of banter you'd expect if you're as deep in the software world as I am.  But that's not where it ended.  kik went and got npm involved.

npm's take

kik sent numerous emails over the 3 weeks following the initial email thread with Koçulu about how rude he was to them asking "can you guys help?" repeatedly.  Eventually, npm sent one email to both parties involved with this message. npm:

Hi, Azer. I hear your frustration. The desire to continue to use the kik and kik-starter package names, is clear. Our goal is to make publishing and installing packages as frictionless as possible. In this case, we believe that most users who would come across a kik package, would reasonably expect it to be related to kik.com. In this context, transferring ownership of these two package names achieves that goal. I understand that you’ve committed time and energy to the packages already, and we don’t take that lightly. I’m hopeful that you’ll be able to republish this project with a new name. Bob, Can you provide an npm account to transfer the name to? Thank you both for your patience and understanding.

So npm's decision was to transfer the package from one account to another.  As anyone who's lost a battle would be, Koçulu was offended and decided to remove all of his code from this particular package manager.  He even sent a reply with an explanation. Azer:

Isaac; I’m very disappointed with your decision here. I know you for years and would never imagine you siding with corporate patent lawyers threatening open source contributors. There are hundreds of modules like Kik, for example, Square; http://ift.tt/1S8JJRm. So you’ll let these corporate lawyers register whatever name they want ? Noone is looking for a Kik package because they don’t have one. I want all my modules to be deleted including my account, along with this package. I don’t wanna be a part of NPM anymore. If you don’t do it, let me know how do it quickly. I think I have the right of deleting all my stuff from NPM.

He deleted code?

Well, no actually.  He didn't delete anything.  He just "un-published" them.  You can still get access to all of his open source code on his github account.  He simply doesn't want his code in the package management system that screwed him over.  Sadly, the package management system he pulled his code from is the one that everyone uses so it broke everyone's code (remember that Jenga tower again?).  It was relatively easy to fix things, but most people weren't aware of what was broken, so it resulted in a very big freak out (which is why I called it cardiac arrest and not death).

But I didn't notice

OK.  To be fair, most people didn't notice.  Most build processes are smarter than to publish code to production when something like that breaks.  But the developers who were trying to publish code to production on Tuesday noticed, and that's what the big freakout was.  In the software world, many companies publish code to production multiple-times per day, so you can see how quickly this becomes a corporate meeting. In fact, npm "fixed" the brokenness by re-publishing the left-pad package.   npm's Laurie Voss made the call here.  And later, npm published a followup about the decision.

What's the contraversy here?

So most of the discussion is about the argument between Azer and kik, and about this "unprecedented" move by npm to re-publish an un-published package.  I'm ok with all of that.  I expected the argument, and I am even ok with npm choosing to publish someone's package without their consent.  It is open source after all.  I tend to side with Voss on this one: Voss:

In the meantime, several thousand open source projects have been repaired, and I'm sleeping fine tonight.

I have the same problem that Koçulu had to begin with.  I think that npm should not be handing over projects to other users.  That's a dispute between the parties involved.  For npm to act as arbitrator in the situation is inappropriate.  Moreover, to hand over a project from someone like Koçulu who has published over 270 open source packages to npm and knows the team on a first name basis to someone like the kik team, who sends nasty threatening emails to that same developer is wrong. We're talking about a community here, not just one guy.  They may have made the kik team happier, but they damaged the community as a whole.  They took the non-contributor and put him above one of their top contributors.  That's very wrong to me. For completeness, and those who want it, here's the code that broke the "internet" for 2.5 hours.

module.exports = leftpad; function leftpad (str, len, ch) { str = String(str); var i = -1; if (!ch && ch !== 0) ch = ' '; len = len - str.length; while (++i < len) { str = ch + str; } return str; }

[deltreey]

So I'm coding all the time.  As a result, I find it somewhat hillarious that my github stats don't show it, mostly because I do a lot of my coding on private repositories not on Github.  In fact, as of late, I'm thrilled to be using my own GoGS server.  It runs great on one of my raspberry pis. I've been coding a lot of javascript lately, so this post will be heavy in js terminology.  Don't mind that.  The sum of it is in the title and the screenshots.

What I actually did

Last night (this morning?) I forked a repository of an npm package I'm using in one of my projects.  I needed some new features added to it to make it work with the project, so I coded them.  The work spreads across 4 commits. It wasn't much, and the commit to fix the tests didn't work because the original author wrote tests that assumed a specific timezone, so this wasn't yet pull request material.  To keep it simple, I put the commits on the master branch and simply point my project at my fork instead of the released versions of the project. Later, after some sleep, I started researching base for my fork only to realize that the author hasn't even looked at pull requests since July of 2015.  So I looked at some other forks, and considered basing my potential pull request off of a more recent version.  Instead of just doing that and abandoning what is definitely the basis for the project on npm, as a courtesy to the author I posted an issue that the project appears to be dead and asked if we should redirect to a more active fork. So, naturally, I expected Github to track my activity and show it in my contributions page.

What Github says I did

I noticed a few months back that github doesn't put anything on your contributions page if you are working on a branch that isn't "master" which must be annoying for people who don't use master as their main branch, but I can understand it and it results in "eventual" consistency with contributions showing up when your branch is merged into master.  But that seems silly. What's worse, I noticed when I left my last job, that when you leave a team, your contributions to that team's private repositories no longer show up on Github either, but I guess I get that too...to the same extent. As of a few weeks ago, I noticed that issues showed up as contributions on this display.  I can understand that issues are important, but to track them while not tracking actual commits....whatever I guess. All of that helps it make more sense when you see that, even though my contributions are to a public repository on the master branch, they don't show up because the repository's a fork...But then I realized something extremely unpleasant.

That's not just wrong, it's detrimental

Leave aside the fact that this encourages people to spam meaningless issues onto every repository they can find. I'd like to remind you instead that: I'm using the forked repo in production.  That means that the information that github is showing is actually the opposite of what contributions I've made to software development today. I don't know what to say.  Maybe I'm using github wrong.  Let me know if you think so.  Otherwise, feel free to share your own github stories.  What's weird about github to you?.

[deltreey]

I've been programming since I was little.  I'm not just someone who wrote some code once when I was 15.  I code all the time because I enjoy it.  This industry is both very deep and very wide.  The ocean of available knowledge is what attracts me to it.  I bore easily, and the idea that I can always be learning something new is extremely appealing.  But, though it may change, at this point in time, I'm the exception, not the rule.

Not every programmer started as a kid.  Not every programmer does in for the sake of programming.  Most do it for the ego trip, or worse, the money.  But having the level of passion that I have for programming is something to be proud of.  That means that many people who do this job for other reasons--well, they fake it.

But it's complicated

Like I said, the industry is a vast ocean of information.  This means that the tiniest amount of knowledge in an obscure enough area (it doesn't even have to be that deep) can give a person the appearance of being more skilled than someone who has spent thousands of hours more time studying other areas of development.  Let's name these people for simplicity.  Phil will be our name for the programmer who happens to know something extremely obscure (let's say he's an awk expert).  And Bill will be our name for the programmer who knows a lot of things, but has never heard of this obscure technology.

The thing is, Phil gets respect over Bill because of this knowledge.  "Even Bill doesn't know it!" say his co-workers.  Sometimes, Bill even compliments him.  "I wish I had your knowledge".  Phil doesn't know what Bill does, but he doesn't have to.  He was hired for this specific purpose.  And this is all great.  Phil gets lots of praise.  His ego inflates and he might even start to get the impression that he's actually a better programmer than Bill.

And then things get complicated

Bill, Phil, and the rest of the team are invited to a meeting by Mark, the new project manager who is trying to plan out the next piece of software that the team has to build.  Bill is excited.  He presents a new piece of technology and explains how it will fit well on the existing technology stack.  Phil gets excited as well, and explains how this new branch of his obscure technology is perfect (maybe) for the problem area.

The team, having spent years complimenting Phil on how much smarter than Bill he was, backs the idea to use this obscure technology on the project.  A decision is made and Bill has to make it work.

Do you see it now?

Bill is now responsible for a project written in a technology he has no knowledge of.  Phil, while extremely confident, will have no actual involvement in the project anyway.  The project will be written in an extremely obscure technology, making it harder for the team to get up to speed and learn what they need to get the job done.

The project will fail

It's worse than just the team learning about the technology.  Phil doesn't have knowledge of the existing production stack, the vital knowledge that Bill has to use when making decisions about what tools to use for the project.  Using this obscure technology will actually be impossible for this company, but even the developers don't know that soon enough for it to be able to help.  The business has no clue.  The company will spend a lot of money on changing infrastructure to fit the needs as the developers discover they need this and that to make it work.  And then, when they're mostly there, they'll realize that it's close enough to impossible that the business is not going to waste money on it anymore.  And it gets worse than that, but let's not focus on the negatives.

What about Phil?

Well, Phil hasn't been working on his project.  He won't get blamed when it fails.  Because he understands most of the technologies involved, he may get consulted on parts of it, and seeing the rudimentary mistakes of the other developers learning his technology he may even think it's failing purely because they're incompetent.  It's not his fault either.  His line of thought is perfectly reasoned based on the information he has.  But then, that's the mistake isn't it.  The information he has is incomplete.

This is a common issue in the pursuit of knowledge, and I wrote this post to explain why it manifests itself so strongly in software development.  But with that explanation, it's also inspiration for a new way of thinking.  As much time as I spend studying obscure, deep, complex bits of software, I don't spend as much time talking about it.  Like Phil, I certainly want to talk about the cool stuff I was studying, but I don't usually get to.

Back to basics

Instead, I spend most of my time talking about simple things.  Even skilled developers often have a weak understanding of testing, readability, and sustainability.  That's what I recommend you talk about also.  If you're ever in Bill's shoes in a meeting trying to deal with an ugly situation, stop.  Don't argue about a topic you don't understand.  Fall back to the basics.  Talk about sustainability.  Talk about testability.  Talk about readability.  But above all, remember.  It's not about today.  It's about the long term.  In 6 months, you're going to have to explain what happened.  Be clear and concise.  And above all, remember, you don't know what you don't know.

[deltreey]

I write a lot of code. I go to work and I code. I come home and I code. I code for charities in my freetime. I code for custom electronics when I’m bored. I code video game playing programs when I need a break from, you know, coding.

The thing is, because I code for a living, not everything I write can be open sourced. And a lot of it might have private information in it that I don’t want to publish to the public. I like to give back to the community. I sometimes donate to open source projects. I pay for the software I use. And occasionally, I manage to give away some code to the open source community.

Code is hard

I get it. Believe me. Code is hard to write, and even harder to read. People are afraid of being judged because programmers (and I include myself for sure) are jerks. And worse than a bunch of people saying nasty things about your project is the prospect that no one may ever care to even look at it. Ever.

But I gotta code

I don’t care. I’m going to code anyway, and some of you are too. We have to. We want to make cool toys for our kids. We want to build tools to make our families lives better. We can’t not code. Programming is the future. Everyone will be doing it eventually. It’s just a part of life today.

We’re going to create software because that’s a part of life. We’re going to create new things and recreate old things. There’s software to automate life, and software to create vintage toys. Software powers everything. It’s going to get written. It’s going to break down. Like everything, it’s going to need changing.

But then what?

As a gamer I have a tendency to plan ahead. I try to think about the future so that I can plan my next move in a video game, and make my life better in the future. This mentality extends itself to my code, and so I think about what happens after I’ve written the software. I’m going to want to change it. I’m going to want to maintain it. I’m going to want to share it someday.

That lends itself to building the code to be maintainable and spend time on design and architecture. I build servers to run my code long-term. And naturally, I use source control.

But source control’s not everything. You need redundancy!

Use Github

So I use Github to keep my code in a second place. I use GoGS locally on one of my servers to keep my software in two places in case my hard drive dies, but when I think the software can be contributed to the community, I put it on Github so that everyone can get to it and contribute if they are interested.

It helps reduce the worry about what other people think if I’m doing it for me and not for others. Since Github is my redundancy server, if it turns out people care, great. If not, who cares? I have a backup!

Use libraries

If you believe anything I’ve said so far, then you understand that the amount of code in the world is only going to increase in time. And much of it is the same. New languages are just a bunch of code written in one of the existing languages with a new syntax. And writing that a thousand times for every device in your house is a lot of work…And then what if it’s broken? Then you have to fix it in 1000 places.

That is not a sustainable way to make the world work in the long term. You need reusable pieces of code that can be updated everywhere with a change in one place. This is what we call a library.

But libraries are bad!

Lots of people say that using libraries is bad because you’re reliant on other people for code.

This is a dumb argument. You can write your own libraries. More than that, you can write your own interfaces to make sure a library is doing what you want it to and doesn’t change and break your stuff. And it’s not like code can change after it’s on the server. The libraries are there for good. Plus, you can manage your libraries! Most companies do.

Libraries are the best

Not just in terms of code quantity, turning thousands of lines of code sometimes into a single reference, but in terms of saving time on architecting and designing good APIs and functionality, libraries save a lot of effort. Libraries consolidate similar tools together in a rational way.

But most libraries are big

Libraries like JQuery and Underscore are what some developers would consider small examples of how big libraries can get. And many times it’s wasteful in more than just hard drive space to have an excessively big library. So we build small tools for ourselves to get by. I find myself building custom pieces of code all the time that I know I’ve build before. The problem is that we are afraid of the number of libraries we reference, so we don’t want to have tiny libraries.

Why not?

I don’t see any reason not to have tiny libraries. This is the modern era. Even in the web, they all get minified into a single library for transit anyway. There’s no extra burden. So I’ve been building a gigantic application for a while and I realized I had a bunch of reusable pieces based on functionality I’ve seen elsewhere. Each piece in this case is a single angular directive. Each library is less than 50 lines of code. Pull in each one as you need it. If you don’t don’t. What do I care? I have a backup. But now I can change things in one place and use these tools elsewhere saving hundreds of lines of manual code per application I build.

So here they are

Without further ado. Here’s 6 angular directives published in the last 2 days after extracting them from my code.

http://ift.tt/1TEmrVk -> http://ift.tt/21TDjgU http://ift.tt/1TEmsIX -> http://ift.tt/21TDkRP http://ift.tt/1TEmrVo -> http://ift.tt/21TDkRR http://ift.tt/1TEmsIZ -> http://ift.tt/21TDjgX http://ift.tt/1TEmsJ3 -> http://ift.tt/21TDjgZ http://ift.tt/1TEmsJ5 -> http://ift.tt/21TDkRT

[deltreey]

Over my years in software development, the one topic that comes up a lot and is often ignored is environments. So here, based purely on anecdotal evidence, is what I know about software environments.

There are seven environments

I know about seven environments that software can run in. Are all six necessary? Probably not. In some cases they even serve similar purposes. The truth is, you only ever need ONE environment. The others serve the purpose of improving the one. That one? Production.

Production

Beta

Staging

Quality Assurance (QA)

Test

Development

Local

Production

Production is the one and only environment that matters. Production is where your code sits when people are interacting with it. Whether production is a webserver, on a distribution channel where people download and install your application locally. What matters is, your production code is the code that people rely on, bug report on, and request features on.

Beta

Beta is a form of production. A beta environment is the environment that your less risk-averse users will use to get the latest features of your application sooner. This means this is basically a slightly buggier production environment with more features. This also means that this environment is technically a subset of production.

Staging

Staging is a copy of production. The staging environment is where you demonstrate new production features before they go into production. Often times, staging uses the production data for read, but doesn’t write to it. A great example of staging in action, is a demo site that you show clients what your application looks like, fully functional, before selling it to them.

Quality Assurance

QA is the environment your manual testers use. If you don’t have a team of testers, you probably don’t need a QA environment. It is a form of a test environment, with the exception that it is deployed code in the exact same way that production code will be deployed so that your testers are not dealing with tweaks made by developers that may or may not have happened in production. The idea is that your testers can deploy the latest version of the application to the QA environment and see if it works.

Test

The test environment is usually used as the QA environment, but ideally it is a more flexible environment that developers can test against as well. This means that sometimes it is used for performance testing and load testing an application, which would make QA unusable if testers were working in it.

Development (Dev)

The dev environment is just for developers. This environment often has custom tweaks, is constantly breaking, and serves the purpose of a realistic environment for developers to test out the new features their working on. In many places, the development environment is the local environment, but that is not always the case. It’s important that dev and production be separate, because otherwise, when developers are trying something new, they’re likely to cause you to lose users when they break things.

Local

The local environment is the develper’s computer. This sometimes includes the code that matches the development environment, but some companies have almost nothing local except what the developer wants to use to edit code (text editor, IDE, etc). Everyone has a local environment, even you, reading this post.

What does that mean?

A great way to demonstrate this may be to use this blog as a comparison. As a blogger, I write my code on my computer in a web browser. The computer and web browser I’m using is my local environment. The blogger editor I’m using is from google, on their servers. That tool is my development environment. Blogger lets me click “preview” and see my blog post as it would look when published. That is my test environment, which since I don’t have testers doubles as my QA environment. I don’t release multiple versions of my blog posts, so I don’t have a beta evironment. And what you’re reading right now is my production environment.

Why would I need all that?

You don’t. Many companies don’t have half or more of these. Moreover, it’s important to understand that most companies mix up the names. I can’t name the number of companies that used their “Staging” environment for QA. Very few companies have need for a Beta environment: Netflix, Twitter, Google. Even less companies I know of have all three of Dev, Test, and QA. Usually they mix either Dev and Test, or Test and QA. And often, as above, Test and QA are mixed into one environment called “Staging” and there is no other Staging environment.

So how do I know what I need?

Expand as you go. Like you do with the company, as the complexity and needs grow, so does your development team, and so does your need for environments. I’m currently working on an application with one other developer and 2 testers/users. Always paranoid about quality, I have 2 environments currently: Local and Test. I have no need for a Production environment yet, as the application is not yet finished. That said, the complexity of the Test environment, and it’s use has grown to the point that I think it’s time to add another environment. Because my “users” are using the Test environment to insert data that I plan to later use in Production, I’m converting my Test environment to Staging, and creating a Development environment that is separate from my Local environment so that I can verify things work a bit better without breaking the functionality my users need.

What’s right for me?

Nothing is perfect. In fact, while this list is somewhat comprehensive, I’m not perfect and there are probably other environments people use that I’m unaware of. More than that, some of these environments might split out into multiples. Perhaps you have a Staging for Production and a Staging for Beta. Perhaps you have a Beta for each new feature you want to test. Perhaps you have one Development environment per developer, one Test environment per new feature. What you need depends on your team and your functional needs. It’s up to you what works best for your team, but it’s important to know what’s out there, and that’s what this post is all about.

Other environments you know about? Let me know in the comments.

[deltreey]

I talk a lot about testing on this site. Part of that’s because I don’t know what I’m doing all the time, and part of it’s because I’m an egotistical developer and getting things right is important to me. The problem here is that tests aren’t what I want. They’re an attempt at a solution to a bigger problem. So this post is about that much bigger problem.

Metrics suck

Let me start by pointing out that there are 0 good metrics in this industry. If you built some tool that does metrics, you might not like hearing it, but it’s completely true. Part of it is our fault, and part of it is a general lack of education. Here’s how this works in another industry where we build things.

The construction parable

Say you hire a construction contractor to build your home. You’re a savvy buyer and you shop around, so you get a really good deal. Along the way you notice that buying the most expensive contractor costs 3 times as much as you’re paying and you wonder how he gets any business at all. The contractor comes in and works on your house for a while. As is expected with the lowest bidder, there are some delays, but you don’t stress about it. Even with the extra hours you’re still getting a good deal. You drop by the site of your new home to check on progress and you realize that he underestimated. There’s not even a frame up yet. You theorize that this is going to take much longer than even his current estimate. It’s going to end up costing more than the next lowest bidder now. Time to shop around again.

So you take another look at the highest bidder. What’s he doing different? Does he never have a project run over budget? He is a dick. He tells you that you have to pay him just to come out and take a look at the project. He won’t even give you a vague estimate. You pay for him to come out. The way you see it, you’ll need to know what your current guy is falling behind on anyway, so maybe you can use this information to negotiate more effectively. His jaw drops when he takes a look at the property. “I’ve never seen that before” he says smiling as he looks at you unfinished building. He finishes looking around and comes over to you and says “We’re going to have to start over. It’ll cost you extra because I have to tear all this down.”

What?! This guy has spent 5 minutes here and he’s telling you that all the money you spent was wasted and that he is going to raise his already absurdly high price. “Why?” you ask, perturbed by his non-chalant nature. He pulls a tool out of his belt. You know this tool. It’s a level. Everybody knows how to use a level. This guy’s not that smart. You know that you just look at the bubble and get it between the lines. He walks over to the half-finished building and places the level down on the concrete. “Your foundation’s not level.” He says, motioning to the tool. You bend over and squint. He’s right. He’s going to have to pull out big equipment to tear up this concrete and replace it. You begrudgingly grab your checkbook and work your way onto his already overbooked schedule.

That’s not how it works in software development

In our industry, it’s very very different. Here’s how that goes. If you’re the guy who knows good software when you work with it, it’s not easily identifiable after a five minute walkthrough. It takes months sometimes. Then, when you can identify it, it’s hard to describe simply to your employer. You can’t show them on a tool they understand, like a level. There is no simple way to show people that you need to rebuild things from scratch. Given that, your employer’s not likely to grab his or her checkbook.

It’s worse than that though. Because there’s no simple explanation, there’s not an easy way for an employer to identify the best hire from the worst. This means you’re not able to charge 3x more even if you’re a 10x developer. It doesn’t stop at pay though. You can’t even convince the guy that you need to tear it down and start over. After all, that’ll take longer and cost more money. So instead you’re doomed to a job where try to prop up a broken frame with toothpicks while users constantly demand better/faster/newer features.

Sadly, it doesn’t stop there either. Because there’s no simple way to show your employer good code from bad, there’s also no simple way to show your employer good programmers from bad ones. You can find yourself in a room arguing with someone who never writes good code, on a topic where he/she is completely wrong and still have your employer side with him/her. This further perpetuates the problem above, because now he may be the higher paid contract to purchase and people will take his word over yours, even if you’re right!

The downside here is that, with something like construction, if you work for one place and do a crappy enough job, they take away your certification and no one will hire you. In development, if you do a crappy job (for very high pay at the moment because of the ridiculous demand) you can still go to the next place and try again.

But this is our fault

I said it might be our fault. It is. We don’t explain things to people. Programmers are notoriously short on patience. I can remember my first time being told what a shell was, trying to log on to an existing one that someone linked me to and asking “what is this, I’m lost” only to be kick-banned with little more than an “lol”. But patience isn’t our only weakness.

We’re also liars. With the patience we lack, comes our human desire for childish pranks. There are probably some of you out there that have convinced your boss that you spent the last month working on “the flux capacitor” just to see if he’d buy it. Heck, it’s so prevalant that those sort of pranks are now put on TV.

And people are imperfect. Some programmers have taken that pranking a step further and chosen to go the less “harmless” route. They use lies like that to justify spending too much time on a project. A 16 year old kid can lie to a 45 year old man’s face because the programming knowledge is so specific and compartmentalized. It’s impossible for us to determine any of this without a decent tool.

It’s a lack of education

The truth is, it could all be solved if everyone everywhere was given a basic understanding of programming. They need to be able to use the basic tools, much like we can all use a level. It’s not something that will happen quickly or come easily, but it is a simple way to fix this problem. It’s also largely due to a culture problem. Learning about computers, even as prevalent as they are, is still seen as nerdy and uncool. If we want people to understand things, then they have to be included, and they have to be a part of the club–which also means the club needs to be less lame.

How can we fix it?

To be honest, I don’t know the answer as to how to fix this. I know that what we need is easier to use tools that people are educated in how to use. I don’t know what that is, but I’m going to keep looking.

The maker movement is going a long way toward expanding education about electronics and software, but it also results in more low quality products and low quality developers.

The FCC is trying to fix it by regulating the things you can do with your own electronics

There are now companies offering to certify your code, but how do we know what the quality of their certification ability is? Half the time, their real goal is to sell us their team of developers instead of our own anyway.

So lots of people are trying new things. My company is going to attempt to offer option 3. I’m a maker myself, doing option 1, which sort of precludes me from wanting option 2… So everyone’s trying to fix it. Now we just need to actually solve the problem. Ideas? Comment below.

[deltreey]

via Twitter https://twitter.com/doltreey