Month: May 2016

You have just spent the last few month going through that awesome course learning all the basics of coding. You can now write scripts that can automate almost anything your mind or your clients mind can conceive. But the desire to continue learning is strong so now what next?

All to be great developers will be at this position at one point in their life. Yearning to get in more technical knowledge but diving into advanced materials almost certainly takes you to theory or project management. Not fun things, at least not for now.

Thankfully for you at this stage there is still a lot more to learn.

Coding styles

Most languages and particularly the open source ones are quite laissez faire when it comes to their attitude on how you style your code. When working with a team, individual style adds complexity to the codebase rapidly degrading its quality.

Thankfully most languages do have a coding guideline. Learning the one for your language will be a good investment for your career.

Error detection and Exception handling

By its very nature, code is complex and not amenable to intuitive thought. As such you can expect that your code will contain errors. That by itself is not a problem, the challenge is how do you keep the system running even when such exceptions exist?

All modern languages offer some sort of run time exception handling. Make generous use of asserts in your code and your weekends will be peaceful!

Learning defensive programming is definitely an investment to consider at this point.

Automated Testing

Writing code is easy, changing existing code is a nightmare. You can prepare for the eventual scenario in which you have to change your code by baking in automated tests.

Automated tests should be FIRST

F – Fast. If you have to wait more than a few seconds for the tests to run, you will likely not use them very much

I – Isolated. To ensure you can quickly narrow in on the problem

R – Repeatable. Running your test should not change state of the application. That way you can run it many times

S – Self validating. Tests need to only give a binary yes/no.

T – Timely. Don’t say you will write the test code later. That never happens

Tools of the trade

A good carpenter would have no problems differentiating between a Socket, Allen or Pipe wrench. As an upcoming developer you should familiarize yourself with the various tools that you will be using on your day to day job.

Your community

Coding is often associated with lonely hours in front of the screen. But it doesn’t have to be like that. Unless you are in a very remote area, there is likely a meeting of like minded individuals going on regularly near you.

Attend this events with fervour. The benefits are amazing. Apart from the chance to discuss your ideas with a human being who understands what you are saying, you grow your network which will pay off in opportunities later on.

That should provide you with some fodder for your hungry brain to chew on.

Tell me about your experience on my twitter @jchex or in the comment section below.

It is that time of the year again, performance reviews!. For team leads this is usually a stressful time especially if in your work environment you have different tiers of developers and even worse the tiers are attached different hourly rates. Think Junior, Intermediate, Senior with hourly of 25,35,60.

In this environment a good number of developers will want to rise up the ranks, how do you know who is deserving? What I present here are some behavior changes that are bound to happen as developers mature in their craft. Watch out for them and reward the deserving.

Under promise, over deliver

The mark of a new developer is enthusiasm. Don’t dare kill that energy, it is what the dev will need to survive the perils of learning programming.

When you ask them if they can do it, the answer will always be a solid YES and of course it can be done in a week, it’s just a payment module right? For Project Managers out there you know it never takes a week.

As they mature you will begin to note a tendency for more careful evaluation. The developer will scarcely commit to features or schedules without first doing some research. Even then, what they will commit to will rather be tame. Yet you know they will deliver. What actually happens is that they more than deliver, they delight.

No longer gurus

While the junior developers know that esoteric language feature, they will not likely understand the basics of a programming paradigm other than the one they live in.

The senior likely knew of that feature a long time ago but years of disuse may have pushed it to the edge of the mind or even forgotten. Their code uses common features arranged in simple ways. They have understanding of trade-offs they are making by working with their current paradigm.

No superheroes here

It takes a special kind of person to wrestle with the machine hour after hour chasing down bugs and solving hard problems late into the night. The skills of the junior are just what is needed to do just that. The junior will boast of the number of commits made and their 365 day streak on github.

It is natural to expect that the senior will have now mastered how to even double the time spent on this coding marathons. Yet what you find is that the seniors are actually, for a lack of a better word, boring. They may not even seem to be working that hard!

Yet results come in steady.

Beyond the keyboard

The junior is actually proud of their poor social skills. They will brag of being the smartest kid in the room. Their super human typing skill is the hallmark of their achievement.

A senior on the other hand will have a rich tapestry of skills extending from coding, user experience, design, project management and mostly important people skills.

Visibility

I will be done when am done if there is ever a defining quality of a junior developer, that is it! The mindset of the junior is grounded on big revelations. They will work tirelessly and at the end unveil this great product which everyone will love and they will be the king of the world.

When working with seniors, you will quickly realize they hold no such delusions of grandeur. They understand for most part that the way to build a great product is to discover what that great product is. You will have great visibility as the project goes on and even better opportunities to provide feedback.

Obviously this is not a comprehensive view of what makes a great senior developer, how has the experience been in your own organization? Get in touch with me on the comment section below or on my twitter [@jchex](https://twitter.com/jchex)

Prototype, this is a term usually thrown around by designers and other professionals in the UI/UX space. It is such a shame that the practise is not nearly as popular in developer circles especially considering the great savings in time and cost it affords its practitioners.

A prototype is defined by Wikipedia as an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.

As I have said before waste is evil that includes waste of your own time. In this entry we will be discussing how prototyping is an essential tool in every developers toolbox.

A picture is worth a thousand words

Even for the most eloquent humans, expressing their ideas in words is usually a challenge. Now let us not kid ourselves, as a group we are not particularly eloquent. Prototypes provide a far clearer channel of communication.

By sharing your idea using even a low fidelity disposable image you will communicate a wealth of information.

Manage scope creep

No matter the tool we use there will always be a bit of ambiguity between what you and the client think needs to be built. Why not clear out the air by instead agreeing on a prototype?

I know of a friend of mine who keeps the initial sketches till the end of the project just in case the client gets creative on features but does not want to finance the creativity.

Run experiments

After spending months building a product that no one wanted, Eric Ries quickly discovered that the market does not care about effort. He then started the Lean Startup movement. I highly recommend you pick up a copy of his book The Lean Startup.

A key idea in the book is that you should not commit too much before you have validated your ideas. Prototypes are perfect for this type of work. They are easy to build, show and then discard.

Incremental development

If you estimate it will take you more than a few months to complete any feature, think if you could get some value by instead first building a prototype of the feature. If the feature works and is accepted then go right ahead and flesh it out to full on feature.

This may not be a very popular way of developing software but at least you will not be forced to discard hundreds of hours in effort if the end user rejects it. If the feature is a success then you already have production code ready and you just need to add a few more bells and whistles.

Tap into the most powerful process

In 1975 John Gall came across this pithy observation

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system

Evolution is a very powerful process and you want it on your side.

One way of doing this is by building prototypes and evolving them based on feedback from the stakeholders till a system that is useful emerges.

How do you use prototypes in your own practise? Tell us in the comment section below or tweet at me @jchex.