Learning is a Fight

I just recently read a blog post by Ritchie Yip about what your mentally going through as you advance through the belt rankings of Brazilian JiuJitsu. You can read that here. As I was reading it, I realize how accurate this was. After spending over a decade doing some form of martial arts, and making the transition to JiuJitsu it is nice to read that the feelings of being incompetent weren't just my own. The more I read the article, the more I felt like it could be translated over to my time in IT. So here is my attempt to translate it over.

So let's start with a breakdown of levels and what you feel like. This part almost copied verbatim from the BJJ blog

Script Kiddie - Unconscious incompetence. You don't know what you don't know.

Entry Level/Intern - Conscious incompetence - You know what you don't know.

Junior Level - Conscious Competence - You know what to do.

Sr. Level - Unconscious Competence. You do what you know.

The Machine - You’re just conscious.  You’re indifferent to competence or incompetence.  You code or script because you love it. Simple or complex isn't a goal anymore.  Just writing becomes its own reward.

Script Kiddie

A lot of people start with an interest in computers or tech. They will be trying different things to make lines of text show up or the system beep. They will find scripts or snippets of code that they will run. You might know what the result is supposed to be, but you it might not always work out the way you want. You will find a Reddit post or something from 4chan to run. It looks cool, might be malicious, you don't care. You just want to make something work. Then you will expand to more things in different places.

You're going to spend a lot of finding something really cool on the internet, that you are going to try without learning the basics. Things like what is the difference between java and javascript? They are same, right? Or maybe at a deeper level, int vs. float vs. decimal vs. double. They are all numbers right? Just use the biggest one always. This is where a lot of people might decide that developing or working with computers just ins't for them.


Entry Level/Intern

I joined these two together because it just seemed like the place to go. I have seen some smart interns, but I have seen some dumb ones too. At this point you know your limits, and that bar is probably pretty low. You are going to be afraid to try a lot of things without someone looking over your shoulder. A big difference between this stage and the script kiddie is that you are getting a little better at the learning the effect of a script or line of code before putting it in. But you are still going to be surprised or afraid to do anything with out something signed off in triplicate.

There is a good chance that you know what a problem is, you may even know what needs to be done to solve it, but you just can't figure it out by yourself. This is expected, but just know that this is one of the shortest lived levels of knowledge. Once you show that you have made a few good decisions in a row, you might notice that people are just going to give you rights to code or servers. Your scripts and code might go through some sort of code review, it might not. When this happens, you have moved on to Jr.

Jr. Level

At this level a lot is expected of you. You should be writing scripts and code pretty much on your own. At a minimum at this level you are doing bug fixes, minor enhancements, and maybe even finishing up an application or migration on your own. This can be the most nerve racking stage in your career. You know what you need to do to fix a problem, and it is expected that you will just do it. If you don't know how to fix a problem then you research it. Research is key in this stage, because anything you don't know you are going to have to learn. This is something that you should have been doing from day one anyway, just now the problems are much more complex.

Now this will shock a lot of you by my next statement. Just as quick as the entry level to Jr. seemed quick moving from Jr. to Sr. isn't much longer, or will be the longest stage ever. At this stage hand holding is gone, you should know how to fix something or figure it out. Within six months to a year, you can no longer hide behind the title of Jr. You should be a Sr. That being said, there are forever Jr's.

These people seem to never find a way to reach that level where they could survive on their own. They show no desire to get there either; That is the worst part. Everybody knows these people in their place of work. They aren't trusted with complex tasks at all. Either from past experience going wrong, or they pass them off on to others. Then to make matters worse, after a certain amount of time, these people are never going to get better. If you don't make it past this part, your growth will be stunted and you will stay here forever.

Sr. Level

At the Sr. Level you are handed a task and a solution is expected. You will be given little to no guidance on how to do this either. It is almost muscle memory when solving tasks. There is almost no problem that you haven't seen at this point. You are most likely, with time permitting, going back updating legacy code to match your new standard. This is where a lot of Sr.'s might struggle too. It is a humbling experience to go back and look at code that is utter shit only to realize it is your own after damning this person to an inner circle of hell. For most this is the top level, you have came to the end of your journey. You learn new things as they appear to keep yourself entertained, but for the most part you have a whole tool box of skills to solve a problem.

At this level you will be guiding the Entry level/Jr.'s through the dark corners of your code that might be confusing. A teaching role, or at least consulting, will be expected. This will range from hand holding, to just pointing in the right direction. This means you have a great understanding of your code or infrastructure, as this is expected.

The Machine

I couldn't think of a good title for this level so I went with The Machine. This level has a lot of different names; architect, guru, the machine, etc. Everybody knows this person in their office. They seem to know the ins and outs of everything. You can find their fingerprints on a lot of the code and servers. Generally speaking these people are who Sr. level's go to for help. Complex problems are simple to this group, and this group loves solving these things. That is their reward. You show them a new language or server and these people seem to just be able to figure it out in under an hour. Entire applications have been wrote by these individuals.

While Sr's have a toolbox full of tools to get a job done, machines make the tools or hand them out. Whether it be deciding to use Hibernate or entity, puppet or chef, git or Hg, or rolling their own toll that they think is better. Usually they have a not only a broad understanding of something, but deep understanding as well. Like upside down pyramids, rather than T Shaped People.


This isn't a perfect translation, I know. I did what I could do with my knowledge or the all the levels. While the JiuJitsu article was wrote by a black belt, I am not a machine yet. So I am sure there are problems or skills that I might have missed. Comment and add your own examples or updates if there is a glaring omission or mistake.

Anything worth doing is worth overdoing!

The advice of make sure you over do something can be good. When it comes to things like safety features, testing, or verification. But what is a good stopping point for application? I was thinking about this tonight as I was changing a headlight. I am sure that somewhere, somebody thought, "Hey, four bolts and six plastic pop rivets will be great for holding the headlight in place! But we better add two more hidden clips just to be safe." And maybe this person was actually thinking this was a good idea, but I shouldn't have to remove 75% of my front end to change a light bulb. They should have just made the back of the light more accessible.

This doesn't just apply to cars either. Let's talk about a project that I have had to help on and a horror story or two. I have always heard the running joke about software being enterprise, hell you can do a quick Google search and find many examples of joke about this. Here, have one! This is the concept of making things over complicated because....reasons! We can discuss the why later, right now let us begin on a story of one of the first "enterprise" applications that I had the fortune of helping write.

Warning! The next paragraph is going to be a long one.

So the first time that I was introduced to this concept was helping with an excel spreadsheet. Yes, even a spreadsheet can be overly complicated. This spreadsheet was used to write contracts for multi MILLION dollar agreements. This spreadsheet had been around for about 15 or so years being updated through the versions of Excel over time. When I got to it the year was 2010, Excel was 2003. Already I am having a bad time. This spreadsheet took a lot of time to learn, it was pretty massive to say the least. The main problem, it didn't need to be, The bulk of the spreadsheet was about 25 columns wide and only 20 rows tall, or so I thought. I began exploring the Macros and found that there were only 2 macros. I thought this would be cake. One macro was to add a new row or column on a button click for more items or a custom field. The second macro was to save. Pretty simple so far. The save button called to run a formula inside of a cell. Let's go look at this cell. This is where dread began to set in, as I realized that I couldn't find the cell. I was looking for R7, the only problem is that my columns went to N...then jumped to BM....fuck. At this point I had no clue what I was about to uncover when I unhid those columns. What was hiding was a monster. A monster that no man could stop as it flew about the room. A monster of such twists and turns one might think it was made of spaghetti. In these columns were all the formulas to calculate payments on these contracts. Each cell was a concatenation of another. Since this was Excell each cell could only hold 256 characters. Not sure if that limit has gone up or not. Anyway, each cell would be calling multiple cells to build out its formula, and each of those cells would do the same. This was how the original developer got around the 256 character limit. By spreading his "code" across 50 columns. This made my small enhancement that should have taken a day or two turn into a week or two. Since I now have to figure out what is all going on in each cell. I ended up just printing out the contents of each of those cells and making a sort of map to figure out what cells talked with each other. I wish I still had my map, but it was taken from me when I left the project. The other developer thought I was a genius for making this map. I thought I was just being punished for kicking a puppy in a past life.

Now if you skipped that last paragraph, just know that code was written in an overly complicated way and I hated my life.

So how does something end up like this? Clearly the original developer knew macros were a thing, but chose not to use them here. I like to think that it started with just a few cells because it was quicker to put it there than write a macro and things got out of hand. I have done that myself and understand how that can quickly become a monster. But at a point you have to refactor. I have even heard some people boast at how complicated their code is and all I can think is, "why are you proud of this?" Seriously, I might be alone on this, but I am rarely impressed by complicated code. You want to impress me, show me how to take that 100 lines of code and drop it to 10. Take that 1000 lines and find a way to get it below 200. Then I am impressed. So why do some people think over complication is a good thing?

I can think of two schools of thought on this, and I am sure there are plenty of other anecdotal reasons for this than mine, but I have two;  And they both seem to revolve around job security. You make things so complicated that nobody else can do your job. This will get you so far. Because all it takes is a new developer, and the idea of completely rebuilding a new application and you're out of a job. Or, the more likely the scenario. A new developer who is coding things simpler, and finishing way ahead of schedule because people are used to your slow ass taking for ever. 

The second is "security", I use quotes because it is only security by obscurity. Which is a good process, as long as it isn't your only process. Some people like the idea that it takes a lot of time for a malicious individual to find their way around your application. At the same time, it will take a new guy just as long to learn the code, if not longer. I say longer not because the malicious individual is smarter, but because this person is motivated to learn the code. Meanwhile, new guy is ready to bail on the project and call the recruiter back by day 2. 

So let's wrangle up this post with some key points and give a half assed TL:DR to balance out the post about over assing something..

• Don't write complicated code if you don't have to
• Just because you can do something, doesn't mean you should
• Don't mistake malice with ignorance, and vice versa
• Make changing a headlight easier than this!