Wednesday, 20 June 2018

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:




Wooohoo - Bike Jumping

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.

The Sagrada Familia: What Gaudi's masterpiece teaches us about "Digital Transformation"

If you're even remotely interested in architecture (the bricks-and-mortar kind), then you are surely familiar with Antoni Gaudi's gr...