Monday, July 30, 2012

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an elephant in the room if you will.  Most Development Managers weren't good developers.  Many will admit it, if asked in the right context.  There's something I did once, and I hear about it done a lot:  Many developers are encouraged to be managers in order to get them out of development.  The challenge is that, in even the best case, a development manager is going to managing people who are smarter than him.

Let's warm everyone up here with a fact.  Managing people is hard.  It is seriously hard.  It's like politics.  In large part it's about understanding people, reading things they're not saying, preempting their surprises for you, and even with all that there's still luck involved.  So managers tend to be valued highly for these skills which are not just a matter of mastering, but a day to day constant struggle to keep up with.  A good manager is almost limited to not having a personality of his own.  He has to skirt that perfect feared/loved balance with every individual each with his or her own unique personality.

It gets more complicated when we include another essential skill of managers.  Managers must understand the product they're managing.  This means, by default, a Development Manager is going to have to be able to develop.  They may not need to understand a regex joke, but they are going to have to have some understanding of the development process, preferably having worked in a developer's role in the past (for long enough to understand it!).  The problem here is, in it's current state, learning to code is not something everyone knows.  It's the type of thing that is associated (rightfully) with nerds in a dark basement.  This means that most developers will not make good managers.  We're not known for social skills which are, as mentioned, a vital part of the management process.

Then we consider that, if development managers are valued more than developers, and a developer moves to a management role because he was a bad developer, he might perceive himself as a good developer, or at least a good manager.  He's getting paid more after all.  This is probably the worst bit of the cycle that I see, but it's not really helpful to the new person except to know that it exists and be prepared for it.  If you're in this role, you'll definitely benefit from the book I'm suggesting in this post.

So how do you, the new guy fresh out of college, manage these developers.  You probably majored in business management, and maybe took a few CS courses.  I'm going to assume you have a C average, because someone who has a 4.0 is probably not reading this (not because they're better than you, believe me).  My first disclaimer now is: I'm not a Development Manager.  I'm a developer.  So this is from the trenches, not from the perspective of the tallest hill.

My advice, and this is second hand from another developer, is to read the book How to Win Friends and Influence People.  In fact, I should clarify.  Don't just read it.  Too many people say "I've read that" with things that they never really absorbed.  Take this book, and live it.  I don't care what you think makes you unique, and neither do the developers you're managing.  They want you to be like this book.  Be it.  It will teach you how to play that careful balance.  It dances around each person's personalities and teaches you how to get people to do things they just don't want to do.

The second bit of advice is from my experience and advice from other developers.  You are the shield between the developers and the users.  It is explicitly your job to make sure that the nerd doesn't get bothered in his basement.  If someone he doesn't know or care about starts asking him questions he's going to get pissed off, or nervous, or confused, and he's not going to do what you want him to.  One way or another, he's going to start making mistakes and start writing bad code.  If you have ever seen what happens to an unprotected developer you will understand this.  This can be very scary stuff.

The third bit of advice: You're never going to know everything your developers are thinking.  So you need to trust them.  They need to trust you or their not going to keep you informed, but more than that, you need to trust them so that their advice comes with value.  There will be times when the CFO decides that this reporting software is going to save the company and you ask a developer and he tells you it's a bad idea.  Trust him.  After 3 years and $200,000 or more, you'll either have a barely working product that everyone hates, or you'll have abandoned the project.

Finally, and I can't stress this enough.  If your developers are any good at all, they want to code.  They may get frustrated over maintenance or whine about documentation, but they come to work every day and they do the work that you assign them, even when they're smarter than you because they like it.  Trust this fact.  They love what they do.  If you make their work environment a place that they want to be, then their love of coding will take care of the rest.  You don't have to make the work exciting, it already is.  You just need to make sure that they're not working on outdated hardware, not trying to code with 1 hand tied behind their back because of some lame decision, and not trying to do something that they're not ready for.

Wednesday, July 25, 2012

Make a regex for this...

I started this blog as more of a generic overall view of coding, more perspective on higher level ideas rather than line by line code (though I suspect I'll post some of that too) mostly because of how much time I spend on StackOverflow.  I figure, if you need an example of some bit of code, you can find it there, or other places on the net.

This post is inspired by about 50% of the questions I see on StackOverflow which are extremely easy to answer, because they start with "How do I make a regular expression for" and then some random bit of text. I have some decent scoring answers on these because I can answer them in just a couple of minutes with my trusty internet.  So here's a couple of my favorite resources.

First, get a bit of the basics of Regular Expressions down, use Regular-Expressions.info, it's a great site with the best detail in explaining Regular Expressions I've ever seen.  Then, make sure you have a decent test client.  For almost all examples, Rubular is my tester of choice, plus it's written in Ruby which is just awesome.

So that's it, read through the tutorials on Regular-Expressions.info, and plop the sample text into Rubular, and spend a few minutes making all the highlights work right and you usually have the answer to the question, and you can permalink the test sample for them.  I might write a bot to do this.

Tuesday, July 24, 2012

Why use KnockoutJS


I put together a bit of a proposal for my team and thought I'd post it today.

THE GOAL
As far as I know, we’re all in favor of decoupling.

Decoupling code has the purpose of separating code into pieces so that changes are easy.  MVC is an example, in that its purpose is to separate the logic layer (controller) from the view, and pull the objects out into their own little place (the model) so they can pass between the two.

We do this with N-Tier applications as well, as we’ve started pulling our model and logic out into separate projects in visual studio, creating a logic dll and a model dll that is used by the web application (or other application) front end, and separating the database from the webservice from the front end.

THE PROBLEM
In decoupling, some people get a bit too gung ho and try to decouple everywhere.   In fact, you’ll see this on Stack Overflow a lot.  The problem I see is that we’re decoupling at the wrong place much of the time.  If you think of decoupling like making independent pieces of a robot that work uniquely, you would want the robot’s arm to attach to any of a number of robots and work the same regardless.

The difficulty here is that in my robot example, the arm isn’t generic, it’s proprietary.  Here’s a bit of sample code I’m toying with.

Let’s say we decide to switch our back end from C# to Perl or PHP or node.js, or we simply want to reuse this code in another project.  What then?  We can’t reuse this code.  It’s essentially trash.  That’s not what decoupling is about.  We’re supposed to have code that’s decoupled so that it is reusable.

Good decoupling separates the pieces in generic ways that they can be changed smoothly.  We’ve all had this issue when buying a laptop or phone charger and finding out that the makers didn’t use generic hardware.  Instead, we have to buy some proprietary hardware or a new phone/laptop just to get by.

THE SOLUTION
Fortunately, there is a solution.  What if the code I’m showing you instead looked like this:

Look at that, pure HTML5 markup, no mixed in C# (razor’s nice, don’t get me wrong).  The only tweak is that little data-bind attribute.  That’s from the library I’m suggesting that will clean this code up.

KnockoutJS works a lot like some other JS libraries to make JS more object oriented, but it has the most important thing of all.  There are a lot of high-quality tutorials on both the project’s primary website http://learn.knockoutjs.com/ as well as Pluralsight Training.

It can use HTML templates cleanly, meaning it can wrapPartialViews without the need for C#, if we really wanted to go to that extreme.  But the truth is it does it by binding to a Javascript model.  Does this mean we have to re-create our model in JS? Nope.  Knockout can take a JSON string from the server parse it and use it as our ViewModel on the fly.  Basically, on the front end we’re working with the same objects we were on the back end, without any proprietary syntax.

I really think this is the best way to cleanly decouple our View.

Monday, July 23, 2012

So you want to code for the house?

Another question inspired this blog post.  When you're a developer, the toughest part of learning new things is finding a project that's both interesting enough to want to do, and simple enough that you won't get frustrated and quit half-way through.  While every early developer probably wants to code the next first person shooter and make millions, most give up and settle for pong, or a text based game.

Finding that niche, that interesting bit of code to write can be challenging, so here's my advice.  Automate.  Code for things that you find tedious.  Code for things that you see other people finding tedious.  Not only are you able to create a time-saver in the process, but you're also creating a valuable product that may later sell.

One of the replies to the question named a few good ones.  Why not host a database to enter your monthly bills?  Then you could calculate power usage, and figure out whether the AC in the summer or the heater in the winter is costing you more.  You might even be able to put a specific money value to a change-over to compact fluorescent or LED light bulbs.

Monthly bills are something everyone can do, and they're also great for budgeting.  But the truth is, if you want to find interesting projects, you're going to have to look at the things you do every day.  Do you get annoyed trying to post to your favorite website?  Write a wrapper API around the posting tool and create your own that's easier to use.  What annoys you most?  Writing code to solve that problem is not only the most likely to be simple to write, but it's also the one that you'll see the greatest benefit from.  And you'll get to see the fruits of your labor every day.  It's just a good feeling all around.

Thursday, July 19, 2012

Breaking Changes? Don't!

Sometimes other developers give me a funny look when I spend extra time decoupling code, or adding some extra configuration.  I explain to them that it allows for future changes to be easier, and they agree, but sometimes I get push-back and it just doesn't seem worth it to them.  So here's some perspective.

I have a confession to make: I hate python.  I can't stand it.  I haven't always been this way about it though, particularly, the things I hear about it on XKCD consistently make me take another look at it time and again.  The problem is, every time I go to look up some basic tutorials, I plug them into the interpreter and they break.  Even Hello World!

Why?  Because the makers of Python accepted a major breaking change into their code base after the language started to get popular.  In my personal opinion, if you make changes to your language that break a hello world tutorial, then your language can't be trusted long enough for me to spend time learning it.

That's not to say that all breaking changes are bad. Eric Lippert discussed a breaking change in C# 5 that's coming that is perfectly reasonable, and it will affect a large amount of code, as it involves the extremely useful foreach loop.  Yet the breaking change was behind the scenes, inside of a black box to most coders.  The only people that will notice it, are the ones who've been working with the language so long, and so deeply, that they're watching for these things anyway.

Python did it wrong.  The change they made is on the surface.  It's visible to every user every day.  It breaks almost every application written.  It's big, and ugly, and they either didn't consider the consequences, or they were too eager to get the language out there to prepare for this sort of thing ahead of time.

Look, I'm not perfect.  I don't write code that will never have to encounter a breaking change.  I try to keep from having to have breaking changes with good practices, but no one solution is perfect.  When we encounter a change, there's a reason we have change committees, and red tape and paperwork.  It's to ensure we keep things working as expected.  If the change is breaking, spend some extra time to do research.  How much of the code base does it affect?  How often is the broken code used?  How many old programs is it likely to affect?  If we don't consider these options, then who knows what you might run into, and that's why you plan ahead.

Wednesday, July 18, 2012

Dependency Injection for Dummies

In the OOP world, everyone is all the rage about this Dependency Injection stuff.  So what is it?  In order to explain DI, I have to use the term Inversion of Control, so perhaps we should start there?  Well, the truth is, the whole thing is purely about *drumroll please* Decoupling.

When decoupling code, you have to identify the links between pieces of code.  For example, when attaching an arm to a robot, you would have to plug it into a slot in the shoulder.  The decoupled part has to plug into the rest of the code somehow.  However, as with robots, this would get really complicated.  Each piece plugs in uniquely, so if we're plugging in a leg down at the bottom, but it's not working right, we have to check the connection there.

IoC is like having all of the plugs in the robot's head.  The parts might be shaped differently in order to plug into the head, but they're the same parts.  In programming, IoC is the concept of selecting the decoupled parts at the beginning of the code, rather than somewhere in the middle.  A more realistic programming example may help.  If we are writing code for a printer which has to print a picture, we're going to have code to select the picture, and define the size and layout of the paper.  Somewhere way down at the end, we'll have the code that actually starts the printer and prints the picture.  When we decouple our code, we remember that some day the user may want to switch printers, or maybe even use a 3d printer, so we'd decouple our printer code, or make it work on its own, like a robot's drawing hand (as that's essentially what it is).  In IoC, when we start up the program, the first thing we do is select which printer code we're using.  If you fail at IoC, you select your printer right before you use it, and you won't know until that point that the user plugged in a different printer today, one that you haven't written code to support yet.  The whole thing would throw an error much too late.

OK, so that's IoC.  What's Dependency Injection?  Dependency Injection is a pattern to use IoC in your code.  It's just a way of doing it.  Dependency Injection is based around using interfaces (or abstract classes) to create a contract for how the code will work. Then, your classes implement those contracts and, in theory, the other code in your project doesn't care how the classes implement the contract as long as they call the methods defined by the contract.

For clarity, we'll look at an example.  In our printer code, we might write an interface that defines a method called PrintImage(byte[] image); and then, we'd implement it with some printer-specific code about how to make that byte array into ink on the page.  All that matters to the calling code though is that it can call Printer.PrintImage(myImage); and not how the code implements it.

Now this is cool in concept, but it's pretty complex in practice, ok not too bad.  As a result of the complexity, there have been a lot of people out there who built a DI Framework of their own.  I personally have used Ninject and Unity, and, to be honest, as long as I can assign the interface a class just once when I start the program, and it populates all of my parameterized constructors, then I don't really care which framework I'm using.  Take a look at DI, I'm sure you'll find it easy to use, and great for decoupling code.

Monday, July 16, 2012

Debugging? Write more tests!

I see a lot of people on the internet talking about writing unit tests.  While they can provide tons of advice on when you need unit tests, I don't see a lot of people talking about how to start.  I mean, you're not suddenly unit testing on a brand new project.  You're going to likely start with a few thousand lines of spaghetti code.

So where do you start with that?  How do you test the untestable, extremely tightly coupled code that throws errors on every page?  Do you even bother?  Shouldn't you fix it, refactor it, then test it? ABSOLUTELY NOT!*

Unit Test First!
I cannot emphasize enough how important it is to test the code before you change it.  How are you supposed to ensure that existing functionality is kept if you don't find out what the existing functionality is?  Sure, it threw a bug on every page, but they were expected bugs.  They might be accounted for elsewhere in the code, and your change could break everything.

OK, that's out of the way.  You can read lots of websites that try to define what a good unit test is.  The truth though, is that if you're not writing a test in the first place, you're problem isn't defining a good test.  When I get a user story, my first task is to write a test that would verify the functionality expected in the story.  Usually, this test ends up being an integration test, though it's technically called an acceptance test, but it also helps me to define the parameters of my unit tests.

So if you decide to heed my advice, to Unit Test before you refactor, and you start with a massive pile of spaghetti code, the only place you really can start is with some integration tests.  Then you find the units you can test, then you slowly start to decouple, making sure all the tests pass as you do.  This is how you start testing code.

As a wrap up, let's give a realistic coding example.  This is our mess of code in a very generic high-level diagram.
You have an ugly database, with an ugly data access layer, all intermingled with ugly code.  Your code probably has lines in it like this:

var sql = "SELECT * FROM codeRepo INTO #tempCode WHERE codeName = '" + fixName + "'";


And half of the company's software passes over that line of code at some point.  This code is not only not unit testable, it's dangerous to test because of the nasty side-effects it could have.  So hop on over to Dev, and build some integration tests.  You'll start with some standard use cases like: CanSaveFiles() or CanBookClients() and this may take a while (a long while).  But eventually, you'll get to the point where you can create a test called ClientCodeRepoFixTest() and you might not even know what the outcome is going to be.  That's OK!  That's what a trusty debugger is for!.  You will just have to figure out what this ugly bit of undocumented code does.  Not only will your job security go up enormously after you do, but you'll be able to make the code work, decouple it, refactor it, and make the whole company make more money.  Then you have a reason to go talk to your boss about that bonus he forgot to give you.

*This is just my opinion, please disregard it if you're a troll

Thursday, July 12, 2012

Prepare for a Programming Career

This post is a result of a question asked on one of my favorite tech forums.

As a programmer I spend a lot of time making sure I'm current.  I like to know what the industry thinks of my choices of languages and I try to make sure I'm learning the most profitable ones.

When I'm looking to keep current, it's important to know how skilled my potential future interviewer will be when I go to sit down for a programming interview.  Sometimes there is a great deal of variance, but overall, this site is a great reference for what types of questions you might get in an interview.  I can't count the times I've been asked about the differences between a class and a struct.

It's important to prepare for fizzbuzz questions.  If you can't answer a fizzbuzz question in the language, then you shouldn't be listing it on your resume.

I thrive on the internet and the massive information that streams about.  That's why I keep up so closely with Stack Overflow and DZone.

It's true that I like a good working environment.  More than that though, I want a manager who respects the importance of quality in software development.  I always ask them about their Joel Test score during my phone interview.  I have had a potentially great interview turn nasty after asking them about this, which proved to me that it wasn't a job I wanted.

I read programming books regularly.  I'm currently trying to get through SICP.  The three books on this list will likely be review for me, but I want to read them anyway.

Short post today, got stuff to do.

Wednesday, July 11, 2012

Decouple that Decoupled Code

Decoupling code is the process of separating concerns. In programming, it refers to separating the code into pieces and ensuring that each piece works on its own. Kind of like a robot might have a robotic arm that can work independently of the rest of the robot.

While not the first, Ruby on Rails has made decoupling popular in Web applications.  Everyone decided to get on the bandwagon here, so even Microsoft came out with an MVC Framework, now in it's 3rd edition.  Developers seem to love MVC.  It's simple, elegant, and most importantly, it's decoupled.

If you ever do Enterprise development, you'll quickly learn that MVC isn't the only way that apps are decoupled.  In many applications, particularly on the .NET side of things, you'll find that code is compartmentalized into components that plug into each other.  It's because of this that I am starting to perceive decoupling as happening in layers.

Let me try to map this out.  In a very very very broad view of things, there is the Database and the application and those things in between.  We'll call these the Database Layer, the Application Layer, and the Service Layer, as this is often how I see things in enterprise code.
Within each layer, however, we find ourselves writing code.  The database gets broken up into tables and normalized.  Each service in the service layer is broken up with a Model, the webservice front end, and the Application logic.  In Visual Studio this is really prevalent because of the way projects are in both appearance and compilation.  Here's an example of a WCF Service.


Then things start to get real interesting.  We see this on the front end as well.  The solution looks like the one for the WCF Service, except the front end is an MVC Application.  That's correct, our Decoupled Project, is full of decoupled Applications, and when we get to the front end, we decouple the front end further.

Now, I'm not going to post my opinion on this.  I'm not even sure if I have one.  But, since we're in the process of decoupling our front end.  Why not decouple the View in our MVC project?  Enter KnockoutJS.  This is a spectacular library for JQuery.  It's purpose is to decouple your HTML and Javascript, enabling your javascript to host your Model and your View Model, while your HTML is a crisp clean View.  Plus, it has some awesome tutorials.

Now we can use MVVM to decouple our View, which is decoupled from our Web Application, which is decoupled from the Application, which is decoupled from the Data.  Dare we decouple further?

Starting a Programming Blog

I'm not a big fan of blogging.  I have several failed attempts in the past, mostly because I don't have the time for it.  I had pretty much sworn off blogging for good pretty recently.  I had mostly stopped reading my RSS feeds from Google Reader.  The only evidence on the internet that I existed was starting to be my site and my Stack Overflow reputation.

But then, SO is kind of a blog isn't it?  I've been posting quite a bit, on multiple Stack Exchange sites.

profile for deltree on Stack Exchange, a network of free, community-driven Q&A sites

I do it, in part because of Eric Lippert's comments,
answering the questions I didn't know the answers to, because those are the ones I would learn from.
Mostly though, I prefer Albert Einstein's reason.
If you can't explain it simply, you don't understand it well enough.
I got a new job...at NASA...as a Senior Developer, and I wanted to be good at it.  I started researching concepts like User Stories in SCRUM and Agile.  I started to monitor things like ISC and DZone much more closely than I had in the past.  I suddenly had a use for those RSS streams again, so I cleared out all my old Economics and Political Blogs and put my programming stuff on there.

Today's Coding Horror post really got me, as evidenced by this blog.  I can really respect his argument that:
you should always finish by writing up your results purely for your own self-improvement, if nothing else.
If for no other reason, I think I can keep up with this blog purely because it is a reference of things I've figured out so I don't have to remember them next time.


So that's it.  I've got a new blog.  Let's see how it goes.