Tuesday, December 22, 2015

You don't know what you don't know

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.

Friday, December 11, 2015

Moar Dependencies!

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.

https://github.com/deltreey/angular-esc-key -> http://deltreey.github.io/angular-esc-key/
https://github.com/deltreey/angular-input-digits -> http://deltreey.github.io/angular-input-digits/
https://github.com/deltreey/angular-simple-focus -> http://deltreey.github.io/angular-simple-focus/
https://github.com/deltreey/angular-input-usphone -> http://deltreey.github.io/angular-input-usphone/
https://github.com/deltreey/angular-input-ssn -> http://deltreey.github.io/angular-input-ssn/
https://github.com/deltreey/angular-input-usd -> http://deltreey.github.io/angular-input-usd/