Beyond the basics

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.

See the entry Name well or go home for more details on style.

It’s all in the data

Not all the fancy syntax in the world can hide the fundamental truth that programming is just manipulating data. It will serve you well in the future to get your relationship with data right.

Learn concepts related to:

  1. Data types and why they matter (Integers, Floating-point, Booleans etc)
  2. Data structures and how they affect performance (Linked lists, Stacks, Queues etc)
  3. Primitive Data structures (arrays, dictionaries, lists) This are important to optimize your code in your language of choice
  4. Databases. There is an amazing array of database systems in the market, it is worthwhile to explore them and their unique offerings

Code flow

In writing your code, your primary imperative is to reduce complexity, see Heart of software engineering.

To do this you may need to learn tools and techniques that can help you refactor your code to make it easier to read.

Some of the most popular principles relate to:

  1. Recursive procedures
  2. Functional programming
  3. Algorithms
  4. Conditionals. Some programming languages offer a rich variety of expressing conditional flows
  5. Literate programming

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.

  • IDEs (Netbeans, IntelliJ, Pycharm)
  • Text editors (Sublime, ViM, Emacs)
  • Source code control (Git, Mercurial, Subversion) actually maybe you just need to know git!
  • Team collaboration (Slack, Gitter, Confluence)
  • Project management (Trello, Podio, Asana)
  • Code repositories(Packagist, Pypi)

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

5 ways to identify a senior developer

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.

Ian Landsman goes so far as to proclaim code is only 5% of the business 10 tips for moving from programmer to entrepreneur

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)

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Why Developers Should Prototype

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

10 common ways software projects fail

A paradoxical scenario plays out all too regularly in a good number of software development studios. The organization hires great developers who have done great things in the past and put them on a project only for them to woefully fail.

Before you go on and judge the team as incompetent perhaps its time to look inward and see maybe the teams fail because of your own managers and the systems under which the developers work in.

In this entry we will be looking at some of the most common ways that software projects fail owing to process failures.

Analysis paralysis

Knowing exactly what is to be built plays right into our need for control. Control over the budget, over the schedule and the time. For all but the most trivial projects, this endeavour is doomed to fail. The reasons for this inevitability are varied, I have previously talked about it in One design to rule them all.

Thankfully the industry has elegantly solved this problem. The answer lies in agile software development. In agile and its practises (XP, Scrum) you don’t need to know everything. You leave room for flexibility as your team knows more and more about the project. See Scrum in 4 easy steps.

Negative peer influence

Throughout our formative years we were warned of this beast called peer pressure. Usually was related to drug abuse, teenage pregnancy, crime and all other decadence of youth.

Yet in our professional lives peer pressure is still as real and even more powerful.

The truth is, the opinion of the group will more likely be shaped by the loudest mouth around. This can negatively affect productivity of your most valuable team members especially if they are the silent type. In case you are wondering a good number of developers are the silent type.

To overcome this kind of peer influence. You need to ensure that your decision making process actively defends against it. An example would be by using anonymous feedback mechanisms and acting quickly to discipline errant members.

Silos

It is natural for team members to feel closer to each other as compared to the other members in the organization. This tendency however can rapidly degenerate into lack of respect or even worse outright hostility between teams.

To beat silos you need to encourage cross team collaboration in a way that highlights the strengths of the team. Self organizing teams working in flat hierarchies are the ones most likely to deliver this kind of collaboration.

Vendor lock in

It’s very easy to get tied into a particular vendor products especially when the products initially boost your production speed. When this happens you lose agility and are forced to build your products around what the vendor allows you.

Some level of commitment will obviously be needed to make any progress but ensure to have done proper due deligence and design your own solution in such a way that the dependency is clear. See Hexagonal architecture.

Over engineering

By and large developers are smart people. Left to their own means they will come up with the most complex design possible for the particular problem you are trying to solve.

Unfortunately the cost of implementing the design may just not be worth it especially for smaller projects or on the onset when the product is not yet clearly defined.

A close cousin to over engineering is gold plating. In this case, the developers put in extra features in the hope of impressing the boss or the client.The strategy largely fails as the client will either be confused by the cruft or refuse to pay for the time used to develop it.

Comprehensive documentation

Documentation is critical to a successful product. Over documentation however steals valuable developer time. It is also worthwhile to note that end users expect the product to be simple enough to use without referring to any documentation.

Invest in good UX to mitigate the need for more documentation, let the product and the code self document. See Name well or go home.

Procrastination

On project onset you likely have months to get the work done. In this cases procrastination sets in

Then towards the end of the project the developers are suddenly on fire working 100 hour weeks to get the project done. This is an unhealthy practise that leads to a phenomenon called the Death March.

The death march is an unfortunate situation where everyone in the team knows the project is headed for failure but continue on anyways.

To deal with this, work needs to be done in defined time box. Scrum allows for this by the practise of arranging work in sprints.

Super developer

Believe it or not super developers are not good team members. The reason is the rest of the team starts blindly trusting on the developer’s super human technical ability to get things done.

Very quickly, this developer will turn into a bottleneck for the entire team grinding work to a halt.

In addition the reverence paid to the super developer may mean you miss out on the creativity of the rest of the team as they wait for all the answers to come from the one person.

If in this situation the best course would be to ensure the super developer shares their knowledge with the rest of the team.

Poor communication strategy

The best way for humans to communicate is face to face period. Using email as the primary means of communication means a lot of the nuances get lost in translation.

In case you run a distributed team, try create an environment that imitates a co working space as much as possible. Tools like slack and hangouts are perfect for this task.

Bad manager

Bad managers come in many forms. The most common being the micro manager and the hands off manager. Both types of managers are bad for the team.

This types of managers drain the energy from the team and suppress their creativity.

Again agile techniques with the concept of self organizing teams and natural authority come into play. Here you let the team be responsible for its own success and let positive peer pressure work for you.

Have any of the factors mentioned above affected your projects? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail