Keeping up with technology

As developers, part of our job is to keep up with technology. It is not an easy task with new frameworks coming out every month, new versions of existing frameworks almost daily in some cases. It seems that it is an unsurmountable task.

I have a very simple tip that helps. 

Stop Doing IT!

You don't need to have 150 github repos of hello world and todo lists in 75 different languages. You don't need to know every nuance of React.js vs Angular 2.0.  I think it is funny that Angular 2.0 is not even used by Google, they are still using 1.x. I'm sure they can justify it some how by the migration would be too much. But honestly, why market a product that you aren't using yourself?

That being said, I am not saying that you should stop learning. If you know anything about me, I'm learning all the time. I learn about devops, frameworks, and languages all the time. But pay attention to the words I am using, I learn ABOUT those things. What I have learned throughout my career is there is no one who knows everything about every programming technology. NO ONE. However, the ones that appear to know a lot often are simply familiar with the existence of a framework/language. If it comes up in a meeting, they are familiar enough to talk about it. If it becomes a possibility as part of the next project, they will go deeper at that time. 

The key to keeping up with technology is to know what you need to keep up with. 

I have coded everything from ADA to Zenith Basic. I made a decision a few times to pursue one direction over another. The best example is when I decided to not master Java since I knew C# pretty well and focus on JavaScript. That decision was the right one. I also decided to try an be an ABAP developer for SAP. I did that. Not my best decision, but as with everything I learned a lot.

Most of my experience comes from projects. I will take on a project and code it up in something I am familiar with, then I will do it again to make it cleaner, more module, and easier to test. I usually do that 3 or 4 times on the same project to see HOW I do it.

Everyone talks about iterative development (I'm avoiding using the Agile word intentionally), however that iterative process is rarely iterative. Keeping up with technology means we need to iterate. Sometimes it may be throwing away and starting again. That is consider waste by the finance people of the world. However, in development, that is considered brilliant.

Why? we are scientists. We do experiments with code to learn new technologies. We do it once, watch it fail, and do it 10 more times slightly different to see if our theory of process works. We are rarely given the time to do that due to, client needs, timelines, and meetings, and distractions, and ... you get the point. How can we prove a process works if we only test it once. We can't. A sample size of one is the worst.

Ok, I'm completely off topic here but I just want to write and share, so here I go.

Note: Sarcasm coming, pay attention.

Let's talk about agile. I love it when people try something for a Sprint and the velocity didn't go up, so they switch back the next spring to the previous process, and that didn't increase velocity, so they switch back again. That is not going to work. The switching alone is a variable that is never considered. Try a process for a couple of months, and make SLIGHT tweaks, not - we need 3 more developers to solve this, and 2 qa, and 2 more environments for PMs to test, and less migrate this to node.js since it is all just JavaScript and everyone knows JavaScript.

UGH! Knowing JavaScript for a browser does NOT mean you know JavaScript in node.Js.

Adding more (ANYTHING) will include ramp up time of the individual, the environment, or the current team on the new technology you decided to adopt this week.

I said this in a previous post, and I think it is critical. Encourage mistakes, be supportive of them. If someone gets reprimanded for mistakes, they will simply be scared to make another one. You have now crippled your team from being innovative out of fear. Almost all mistakes are recoverable, relatively quickly too. I took down production for one of the largest online services in the world on my third day, as a contractor! I was informed of the error and asked can I fix it, I did within 15 minutes. Everyone laughed a little as I sat there terrified if I was getting fired that day. I didn't and the team around me never criticized me or even punished me, they definitely let me know that I shouldn't do that again. :-) It was then I realized it was great to try things, and learn, just don't do it in production. :-)

I know this topic is about keeping up with technology and I think some of the technology we need to keep up with is the processes that people continually refine and implement. 

We rarely give way to new theories because our old ones work so well. Do they? How do we know? Imagine if Google decided that AltaVista search is good enough, we don't need another search engine. Or even further back, horses move fast enough, why is Ford making a new transportation thingy? I always love that quote from him, "If I asked the people what they wanted, they would have said a faster horse."

It seems that people are always wanting something more, and they think if they change enough all the time, they will figure it out. Let me correct you now, you will NOT figure it out by changing too quickly. You need to see how something works longer than an hour, a day, a week.

It goes back to all of these people dieting that I see, they diet for a month and don't lose what they wanted and then switch to another diet. How about you stop dieting, and simply start eating differently. 

I truly believe that the most difficult thing to accomplish in life is consistency.

So adopt a new process, and implement it consistently, for a few months. I generally like to put a 90 day window on things before I even see if it is working. I'm usually amazed by day 30, but I keep my head down and go until 60 or 70. I rarely make it to 90. Like I said, consistency is difficult.

I know that this has become a bit of a ramble about process and technology and even a little life lesson here and there. I truly hope you allow yourself and your team to make mistakes and allow your process to evolve on its own without dramatic swings.

Now go build something amazing!