Turn yourself into an amazing Software Developer

So it's 2 AM now.

My FitBit is complaining that I'm not getting enough sleep, but my mind is telling me there's a problem to be solved.

The Mexican stand-off started at about 1AM until I eventually gave up, so here I am

Yippeeee-skippeeeee!!!

Anyhoo, what's so important that you need to face the winter cold at 2AM?

Well, over the last few days I've been battling head-on with an interesting conundrum of our industry (especially here in the good ol' RSA):

1. There is more than enough work to be done, often leading to projects that are sitting on the back-burner because nobody is available to do it
2. There are tons of people looking for an opportunity to join a project team and build cool stuff.

So surely this is an impossible situation - Let's just put these two problems together and we solve them both.

Not so fast! There's a barrier between the two problems that make them incompatible:

Skills

The skills problem plays the role of the Berlin Wall in my world, because even though there may be countless people available (and yearning) to join cool projects, if they don't have the skills needed by the project, it ain't gonna work.

So we have a problem. And, of course, there are many ways to skin the cat from the company's side of the fence.

But this post is about what an individual software developer can do to improve his/her own life by understanding this problem and leveraging it. In particular, it is focussed on developers who may be wondering why they are struggling to get the opportunities to do the cool things that they want to do.

You may be asking yourself:

"Why am I constantly being asked to do mundane things on the project?"

or

"Why are my job applications constantly getting rejected?"

Of course, I don't have all the answers, but below I'm expanding on a number of steps that I feel each developer should take on the road to becoming a master.

Step 1: Understand that job roles are irrelevant

Our industry is filled with job titles like:

• Software Developer
• Full-stack developer
• Front-end Developer
• Back-End Developer 
• Business Analyst
• Technical Architect
• Enterprise Architect
• Test Analyst
• Scrum Master
• ...

If you decide you're gonna pick an item from the list above and just be that one thing, you're shooting yourself in the foot from the very start.

A Software Developer who is not skilled at writing specification documents is never going to be able to lead teams who create magic. You're type-casting yourself into a corner.

An Architect who just draws diagrams with blocks and lines, but never opens an IDE is never going to be able to make well-informed architectural decisions. You're type-casting yourself into a corner.

A BA who doesn't actively write code on the project is never going to be able to compile requirements that lead to elegant solutions and expose previously unknown opportunities.

Let me say it again, you're type-casting yourself into a corner.

To become a master you must have a firm grip on the skills in each of these fields. Talk to your colleagues. Read the books that they read. Actively engage with the work they deliver.

Step 2: Get a better understanding of expectations

When you're on a project, your team members expect you to deliver. And with the rising popularity of agile methods, the iterations for delivery are getting shorter and shorter.

If you are given a specific task by a senior person on your team, make sure you understand what the delivery timeline expectations are.

In practice we generally work on 2 week sprints. During that time functionality needs to be fully understood, implemented, tested, deployed and then demonstrated to the customer. That means that any given task on a project is generally expected to be complete within 1-2 days.

In addition to understanding the delivery timelines, make an effort to understand what actually needs to be delivered. Always ask yourself the question: "How will I know I'm done with this task?". If the answer is "When XYZ reviews it and approves", then you don't actually understand the expectation.

If it's unclear, talk to people, get clarity, make it happen.

Step 3: Read

I shouldn't need to explain why reading is important, but let me help out by explaining what you should be reading.

The technical book suppliers (Packt, Manning, etc) all have regular specials and even general subscriptions that allow you to read any technical book available.

As far as possible, try to read at least one technical book every two weeks. And when I say "read", I mean cover to cover.

Yes, you may think that while reading Claus Ibsen's book on Camel, you should try to quickly distill the most important facts so you can get back to your IDE and code - But that is a mistake.

Think of it like this: Claus Ibsen is a globally renowned software developer. Surely, between the code examples there are tons of fundamental explanations that will help you become a better overall developer.

If you read books from cover to cover you join the author on the journey, you properly engage with the content and you become a better developer overall.

Don't skimp!

Step 4: Subscribe to an online learning platform

Don't wait for your company to give you a subscription to Udemy or Coursera or CodeAcademy, or whatever.

Take your own career seriously. Get your own subscription and start learning. Select a platform that works for you, but try to pick one that gives PDF certificates of completed courses.

Not only will your skills improve, but if you go to your boss/architect/project manager every two weeks showing the next course you completed you will soon be given the opportunities you've always dreamed of.

Step 5: Exercise

Write code every single day. Get a GitHub account where you can tinker on non-work-related projects or utility libraries that you regularly use.

Often times there might not be sufficient time to build whole things, and for those days you should keep up your score on platforms like CodeWars and HackerRank.

Step 6: Commit and Deliver

This is probably the most important step in the process. Your team members (not just your boss) can easily identify which team members are committed to the success of the project.

Every project has busy times and then crazy times. When the crazy times come, you need to step up and deliver on your commitments. And beyond your commitments, you must be on board with the team's commitments.

If your team members are staying late to ensure a demo is ready for the next day DO NOT WAIT UNTIL THEY ASK YOU TO STAY.

I cannot stress this enough: Immediately volunteer to stay and help, even if the issue isn't related to your work.

If you prove to your team members that you can be counted on when the chips are down, they will do the same for you. People remember stuff.

Closing remarks

We live in a free world, but freedom doesn't mean everything is free. The only way that you'll make your dreams come true is if you grab hold of the steering wheel and make things happen.


And in the words of Forest Gump: "That's all I got to say about that"




Copyright Note: The image at the top of this post is the iconic image of German soldier Conrad Schumann jumping the initial barbed wire fence that later became the Berlin wall. Photo by Peter Leibing, copyright held by Ruth Leibing. Learn more at: https://en.wikipedia.org/wiki/Conrad_Schumann

EOH Connect 2018 :: #DevAnything Talk

If you weren't at the conference, check out the recording here:

https://www.youtube.com/watch?v=qO822wN2IrU 

Join us in the Open Source Revolution

(Note: Article originally composed for EOH EQ Magazine)

Do you remember the famous Times Square scene from Vanilla Sky?

Tom Cruise parks his black 1962 Ferrari GTO in the middle of Times Square. The place is quiet. No noise, no people, and no cars. Just the black Ferrari.

In Times Square!

He gets out of the car and starts walking. Soon he is jogging, going faster and faster, until he’s sprinting flat out. And then he stops.

That’s how I've experienced the digital revolution over the last 20 years. First it was a few websites that I visited regularly. Then I created logins to participate in the forums. Forums turned into online communities. Websites turned into mobile apps carried in my pocket. All the while, innovation picked up pace until today:

•   I talk with friends and family on WhatsApp

•   I get my news on Twitter

•   I keep in touch with parents on Facebook

•   I catch up with old school friends on Instagram

•   I learn new skills on Udemy

•   I share my photos on Flickr

•   I plan my holidays on Google Maps

•   I watch TV shows on NetFlix

You get the picture.

Companies like Facebook, Google, Twitter, LinkedIn, NetFlix and Adobe have become synonymous with the new digital reality of our lives. Yes, these are large companies with thousands of super-smart engineers, but how are they able to build things so quickly? The answer lies in something else that these companies have in common: They are some of the largest contributors to open source software worldwide.

Have you heard of Apache? Sure you have, it runs almost every website you visit on a daily basis. Also, it's fully open source and you can download it for free right now.

Have you heard of Hadoop? Sure you have, it runs almost every big data lake in the world. Also, it's fully open source and you can download it for free right now.

Have you heard of Linux? Sure you have, almost every server in your data centre runs Linux. Even Microsoft has now built Linux into their platform. Also, it's fully open source and you can download it for free right now.

Have you heard of KVM? Perhaps not, but Amazon uses it to run the virtualisation of their AWS cloud. Also, it’s fully open source and you can download it for free right now.

And so it goes on…

Companies around the world have been realising (some faster than others) that the value of software does not lie in the source code, the value lies in how you use it, and in the new world of "Software Platforms" the value of your software often is directly tied to how many people use it.

And if you want your software to be used by many people, then a good starting point is to give it away for free.

Free?

You’re kidding me?

How are we supposed to make money if we give our software away for free?

Getting into the details of the Open source business model requires a bit more time than I have available in this short article, but allow me to provide some examples of companies that give away a substantial portion of their IP as open source software:

• Alphabet Inc, AKA Google, Market Cap = 825 billion USD
• Microsoft, Market Cap = 725 billion USD
• Facebook, Market Cap = 552 billion USD
• Twitter, Market Cap = 18 billion USD

So clearly, there are sufficient counter examples to show that this is perfectly possible. But in addition to simply being possible; in today's competitive IT environment it is essential to work in Open Source, just for your own survival.

A simple example is LinkedIn. In 2010 the company needed a highly scalable messaging system that was both faster and more robust than what the providers like IBM MQ and TIBCO could offer. So they decided to build it themselves. This product gave them a substantial advantage over their competitors in the social media space. However, instead of treating this product as a trade secret, they donated the code to the Apache Software Foundation. The product is called Kafka.

Today, Apache Kafka is used by 7 of the 10 largest banks in the world and 8 of the 10 largest insurers in the world. It has become an enormous success and plays a mission critical role in the routing and ingestion of big data loads worldwide.

A simplistic view of this situation could be that LinkedIn should instead have packaged Kafka into a product and sold it to all those companies. That's what Oracle would've done.

But such a view doesn't consider the whole picture. You see, although LinkedIn started the project, and continues to play a leading role today, there are now 312 active contributors to the Apache Kafka project. About 10 of them work for LinkedIn. So by using open source, LinkedIn was able to use a team of 10 developers to build a product that actually requires hundreds of developers to build.

In other words, by giving a little, they got a WHOLE LOT. More than 300 passionate developers, to be precise. LinkedIn got them for free, and they're building a system that makes LinkedIn a better company every day.

This example shows how the open source community is the perfect place for achieving something that is substantially larger than the sum of its parts.

It's like compound interest for software.

Of course, LinkedIn is not in the business of selling software, so perhaps that's why it worked for them?

Not true.

Many examples exist of highly successful software companies who use open source as a key strategy. For example, Adobe (Market Cap = 99 Billion USD), Microsoft and RedHat (Market Cap = 24 Billion USD). The key lies in not giving ABSOLUTELY EVERYTHING away for free.

These companies strategically invest in open source by giving away a lot of their software for free, but not everything. By giving some of their work away for free they can benefit from the Open Source revolution while also selling proprietary components that add value to the Open Source offering.

So it is possible to make money from Open source, and the most successful IT companies in the world are doing it right now.

We have joined this revolution of Open Source with teams who work on Apps, on Big Data platforms and Cloud Infrastructure. We’re leading the way, and sharing our experiences as we travel. Join us.

Where to start?

What is the state of the nation for software development in South Africa?

We have a big IT industry.

We have many people who are technically very capable

• People who are highly skilled in deploying and configuring infrastructure
• People who are highly capable in creating complex business requirement specifications
• People who are highly experienced in installing and configuring packaged software solutions like ERPs, CRMs and manufacturing automation systems
• People who are highly respected for their ability to compile elaborate and mathematically sound process maps
• People who are exceptionally talented in designing beautiful mobile and web apps

But I have one concern: I'm not sure we have an abundance of people who have the ability to design and develop custom software solutions.

Of course, this concern of mine is based on my own experience. And that experience has taught me that we definitely HAVE expert software developers in South Africa. I'm just not sure if we have a great many of them. Too often I sit in boardrooms where solutions are discussed and technical details are glossed over: "Let's not get technical", they say, or "I'll discuss this with the development team and get back to you".

It seems to me that we have created an industry filled with sales people, account managers, business analysts, solution architects, user experience designers and more. These people are all amazing, and they have amazing ideas - ideas that could well change the world. But ideas need to be implemented.

And I suspect.

Based on some hard-won real-world experience:

That when the time arrives to implement ideas, we are a bit short on capacity in South Africa.

To be fair, I may be entirely incorrect, and in reality this blog is part of my research to investigate whether I am. But the anecdotal evidence all points in the same direction: When we see problems, we look for existing products that we can buy to take our problems away. We buy CRM systems and configure them according to our needs. We buy ERP systems and configure them to our needs. We buy content management systems and configure them to become our websites. And much, much more.

On the face of it, this is a perfectly logical approach. After all, it is definitely faster and cheaper to buy an existing product than to develop it from scratch. But unfortunately, this approach comes with a built-in assumption: That our problems have already been experienced by someone else, and someone else has already solved it.

Which means we have admitted defeat in the innovation race; even before the starting gun has been fired. Innovators are people and companies who create problems that nobody even knew they had. They design a car when others are still figuring out how to make a faster horse.

If Sergey Brin and Larry Page were followers, Google would've created just another Altavista, which in turn was just another electronic version of the Yellow Pages. But they were innovators, and in the process they created a brand new problem: How do we build a highly scalable index of the Internet where search requests return accurate results.

There was no existing product that they could buy and customise with their logo to create Google.

Today, Google is a world leader in many fields, well beyond just search technology. Interestingly, following the release of Elasticsearch v1.0 in 2014, any company could buy a product, configure it according to their needs, slap on their own logo and establish their own global search engine. In effect, ElasticSearch is the productised version of what Google was when it launched in 1998.

So that's the difference between a leader, and a follower: 16 years, and 744 Billion US dollars.

And the same applies to any other field of technology: If you can buy a product to solve your problem, then your problem is old and stale. Yes, solving your problem is necessary, but it is necessary in an effort to CATCH UP, not in an effort to GET AHEAD. If you want to GET AHEAD, you need to start with fresh ideas. You need to assume nothing. You need to create your own problems.

When Netflix wanted to create a streaming video service, the technology for scaling and load balancing such data volumes didn't exist. They couldn't approach IBM to purchase a packaged solution to their problem, because nobody ever had that problem before. So they built Ribbon and Eureka themselves, and that has made all the difference. Today, there are many streaming video services worldwide, but there's only one Netflix and Chill!

So innovation requires breaking boundaries. It requires opening your IDE and writing the first line of code for a new project that exists nowhere but in your mind.

If we want to foster innovation in South Africa, we need to ensure that more people are enabled to write that first line of code.

We need to ensure that more people are encouraged to write that first line of code.

And we need to ensure that more people choose to write that first line of code.

Don't get me wrong; I'm not saying configuration is a bad thing. Many problems that we face on a day to day basis have been solved already, and for those we need to leverage the collective minds of the past. We need to buy tools and configure them according to our needs.

But if we want to lead the way, we need to create new problems.

Don't Fear the Porpoise

This blog is about finding gaining a deeper understanding of the nature and risks of the Software Development industry, with a clear focus on South Africa.

It all starts with befriending the porpoise

If you're not a Walter Mitty fan, here's a taster:

Join me on this journey.

But beware, it can go in any direction, at any time..