7 things an ex-developers needs to learnPosted: May 10, 2013 Filed under: rambles | Tags: agile, cutting edge software, lean, learning, software, technology 1 Comment
Me: Hi, my name is Phil.
Everyone: Hi, Phil!
Me: I used to be a developer. It has been 8 years since I last wrote software for a real system. I still think I know how to code and I’m sure I add value to all design and development meetings, but I am starting to think that things might have changed.
Everyone: It’s good that you are here. We know how you feel.
Me: I was pretty good back then. I was so good I got promoted to running things. I still know how it all works, and I’m not worried I don’t understand the new technologies as I can run rings around these young guys. I now do all of the other managerial stuff and make all the important design decisions, create architectures, commit to deliveries and do all of the planning work. Because I know the technical stuff really well, I can represent the technical team.
Everyone: Oh, dear, Phil. We might need to help you.
Me: Well, what has really changed over the last ten years? Programming is programming. I could still develop today, right?
Things have changed and are continuing to change. A lot.
And, if you are an ex-developer who thinks it is still the same world, you might need to learn a few things as you might just be getting in the way.
Development has changed
I come across so many people who used to write code and started their careers as a developer. I come across so many, I think we might need to create a rehab group for all development managers, agile coaches, team leaders, project managers and other senior executives who think that they still know how to develop cutting edge software solutions fit for today’s customers.
Life has moved on. Programming today has changed. And yet, in some ways it is still the same. But, I believe the differences now outweigh the similarities. The practices used are different Everything is agile. Everything is TDD. It is all continuous delivery. The tools and infrastructure. The frameworks that exist now are so good that you can build amazing solutions in a very short pace of time. The old process of capture all requirements, design the whole system, build it, test it and deploy it a couple of years later has gone.
The problem is that technology expectations have risen. Customers know they want more and now. Businesses want more and now. Everyone wants more and now. Mobile platforms are everywhere. Software is now more open and re-usable. Scalability is a bigger deal today than 10 years ago. User experience is not a nice-to-have. Software is eating the world and everyone involved in delivering products and services needs to understand more about what is being built, and how it is being built. This idea is illustrated beautifully by a passage in the Valve’s Handbook for New Employees:
Non-Engineers: program or be programmed
Valve’s core competency is making software. Obviously, different disciplines are part of making our products, but we’re still an engineering-centric company. That’s because the core of the software-building process is engineering. As in, writing code. If your expertise is not in writing code, then every bit of energy you put into understanding the code-writing part of making software is to your (and Valve’s) benefit. You don’t need to become an engineer, and there’s nothing that says an engineer is more valuable than you. But broadening your awareness in a highly technical direction is never a bad thing. It’ll either increase the quality or quantity of bits you can put “into boxes,” which means affecting customers more, which means you’re valuable.
The tools and practices that help programmers be successful are very different today than when I studied computer science at University. They are certainly different to those that the people who developed the original cobol programs that underpin virtually every major enterprise used.
Storage and databases have changed. SQL is even being challenged. That’s mind blowing for someone who only built enterprise software on Oracle, SQLServer and others that underpin most enterprises today. Is the RDBMS dead? The answer is not conclusive, but there are definitely things to consider. Technology choices have exploded for the modern developer. The start-up scene is doing things differently and they are outpacing the established companies. The open movements in software have created a marketplace that can have the novices’ head spinning. And, whilst I don’t feel like a novice, I wonder if I am.
The first step to resolving any problem is to admit that you have one. So, I am going to investigate many of the latest trends, tools and techniques to see how bad it has become. I want going to explore 7 areas of the latest stuff, and provide a resource for others in where to find good information in each of the areas. I might end up going in to other areas if I stumble across interesting things, but I will start with these 7.
I learned C, C++, Lisp, VB and Java. I hear functional programming is in vogue again. This puzzles me given the shift to OO that happened 15 years ago, and my lecturers insistence that objects were the way forward. I’m sure it is not that straight forward.
Ruby and Python seem to be very popular as they help developers be far more productive delivering web-based systems than other languages. I’ve never come across either so I’d like to see what the fuss is about.
My goal is to learn one or more new languages so I can compare and contrast the different paradigms, and maybe build a little app or two.
Startups are following the Lean Startup methods. Agile is now the norm. People are using the Y Combinator approach to deliver working products in weeks. In the years since I left enterprise software delivery in BT, things have moved on and there is much to learn. Luckily, my company has created the world’s first work-based education programme based on agile and lean. It is time to put it into practice.
Git, heroku and other build and deployment tools
This is an area that has changed massively in the last 5 years. SaaS, PaaS, BaaS, EverythingaaS has my head spinning. Git is very different to the SCM tools of the past. Heroku looks cool. I have done a little bit on AWS, but I think this is an area that needs real investigation. I suspect there is much to learn.
I used to run big enterprise systems that didn’t really deal with front-ends. Usability, speed and rich experiences are important for all sites. This is one area that I really want to explore. My design skills are not great and I suspect learning the languages will be the easy bit. Making good looking things will be harder, one suspects.
So what’s changed here? RESTful architecture seems to be a popular topic. Is MVC something people still talk about? I think there is a lot to look into for scaling software, promoting re-use and creating more maintainable software.
The whole NoSQL movement is intriguing. MongoDB, CouchDB, BigTable and other tools will be tools to examine. I have no idea if this is where Hadoop fits in or if that sits elsewhere. Regardless, another thing to look into.
Modern Test-First Tools
At Christmas, I took the developer test for Emergn. It is a core part of our hiring process so we can see how developers think and what they consider to be high quality. I had never written TDD code before the Christmas holiday. I know test first is really important for design and quality reasons, and I’ve seen the results of high-quality development, but there is much to learn. BDD, Gherkin, Cucumber, RSpec, JUnit, Selenium and DSLs.
I’m sure I should be looking at iOS and Android development too, but it seems like an awfully long list already.
Now all I need is a couple of little projects to provide a backdrop for learning and making all of these areas practical. I am certainly not confident in the amount of new things to look at and I suspect it is going to take a long time to crunch through all of this stuff. Especially whilst holding down a demanding day job. If you have any ideas for shortcuts, useful resources or other areas to look in to, I’m all ears. I will share my findings.