Author Archives: Ryan Lohan

  • 0

Now Hiring: Senior Software Unicorn

[DISCLAIMER: First, for you avid job-seekers, sorry, this isn’t an advert for a role at BlueFocus.]

Whilst we like to pride ourselves on our flexibility and talent, even we recognise that at times, a specialty set of skills is called for. Lately though it sometimes seems that calling for expert-level skills in everything seems to be the strategy du jour. We’ve all seen our fair share of, shall we say, optimistic, shopping lists when it comes to hiring in IT. But this one today really caught my attention.

Now hiring: senior software developer unicorn. Ignoring the grammatical errors in what is clearly a rush-job to hire a master-jack-of-all-trades (which is an oxymoron if ever I’ve made one up), the shopping list for this one doesn’t just strike me as optimistic, it strikes me as chaotic and unclear.

I almost wonder if the client discussion that came before this ad went to market didn’t go something like this:

Customer: We need a super talented engineer to help us roll-out a major software project in the next 6 months. They need to be awesome.

Barista: <thinking> You know, I could be an IT recruiter. I’ve heard of the interweb.

Customer: Oh and 1 sugar in that latte, please.

Barista: <googles>”software awesome project” </googles>

IT recruitment needs to get serious. Dragnet fishing has been outlawed in many countries.

Now hiring: Super-awesome Senior Software Engineer. High 5!

 

The full text of the job ad follows. I think it’s anonymous enough that I don’t need to redact it.


Senior Software Developer

READ: Unicorn. Will pay more for a shiny horn.

Our client is currently in the need of a Senior Software Developer to support them with product development and go-live on a 6 month fixed term contract assignment with. You will be supporting a well renowned and charitable cause while working on cutting edge technology.
READ: Charity. Technology. You know you want to.
You must be able to hit the ground running with a high level of attention to detail with the technology confidence to work autonomously in getting the job done!
READ: I’m not sure what the project is, and nor is my client. I’m sure you’ll work it out.
You will be involved in all stages of the software development process. It involves the development of new products using emerging technologies as well ongoing enhancements. You will be working closely in a small team of 8-10 Web Developers in an open plan office alongside Web Designers, Graphic Designers, Project Managers and Systems Administrators.
READ: Although we have a reasonable team in place, no one is quite working out, so we’ll need you to basically do the job of 10 people.
We are looking for someone with proven software development experience in developing and successfully launching desktop and web solutions.
READ: You must have, at some point, written some code that got used. Anywhere.
Skills: 
  • PHP5, MySQL, Javascript, HTML5, CSS3, Ajax, MVC.
  • JS Libraries: jQuery, Angular, Bootstrap
  • PHP-CMS: WordPress, Drupal and Magento

READ: We want that guy who wrote the internet. We like that.

  • Payment Gateways: PayPal and CCAvenue

READ: CCAvenue shows up next to PayPal in a google search for ‘credit card payment gateways’. (Actually, it doesn’t, so maybe they are already using this technology… a clue!)

  • Web Stacks: LAMP and WAMP
  • Web Server: Apache, IIS
  • OS Platforms: Windows and Linux ;

READ: Some of our team like Linux. Some like Windows. They all have iPhones. Choose your side.

  • C++/ WIN32/MFC
  • C#/WPF

READ: You will be required to be super-awesome with both 20-year-old and emerging technologies. (And we are still using WinXP, but hey it’s a not-for-profit!) P.S: Gen Y need not apply.

  • Development Platforms/ IDE: Visual Studio, Netbeans and Notepad++

READ: (Don’t tell anyone, but we also have some Java code…)

  • Strong understanding of OOPS, Data Structures, Multi-threading and design patterns.

READ: This whole ad sounds like an OOPS to me…

  • Configuration Tools: VSS, Tortoise SVN, IBM Clear Case & Clear Quest.

READ: I’m struggling to understand these search results now…

  • Unit Testing: Visual Studio 2012, NUnit and Drupal unit testing framework
READ: Will not consider experience in Visual Studio 2010 ‘unit test framework’. 
If you feel you have experience or proven knowledge of the above skills then we’d love to hear from you.
READ: If you even feel qualified to apply for this job, you’re hired!

Charlie the Senior Software Engineer

Charlie the Senior Software Engineer

Now, it’s great to aim high. But this is directionless. It’s akin to drag-netting. By posting ads like this, you’re wasting both your time, and that of any potential job applicants.

The shopping list infers a requirement for senior level skills in multiple very-different software programming languages; PHP, Javascript, C#, C++ (we’ll assume that my Java joke was just a joke…).

They want you to have built websites on Windows, and Linux and presumably have experience in building and maintaining the whole web stack on each platform,

“Configuration Tools” somehow managed to envelop enterprise-level configuration management and ancient (OK, pretty old) source control systems. VSS and SVN? Sounds (not) awesome.

If I read between the lines, it really sounds like the project is about modernising or porting some legacy systems. From C++ to Web. For some reason, the client has not standardised on a tech stack. I may likely be off track here, but if the intent is really to find an awesome software engineer, perhaps dumping the shopping list would be a good start.

Why not just come out and describe the project in detail?

What’s wrong with something like this;

“We are planning on launching a new web application in time for Christmas. Our customers currently engage via legacy systems which are partially implemented in C++ and partly in WinForms. We want to port and modernise this functionality onto a C#-based ASP.NET platform. We also have some bespoke PHP applications connected to a Magento e-Commerce platform which require ongoing maintenance, and integration with this new system.

We need a technical lead to help drive this project through to completion, working with a team of 4 PHP experts, 4 junior C# developers and a UI/UX design team.

Ideally, you will have strong skills in C#, and AngularJS, as we will retire these legacy systems at project completion. But if you are able to at least understand some C++/MFC code, or even work through our (incomplete) Rational ClearCase modelling and documentation that would be a plus, as it would really help ensure that functionality is ported correctly.”

I have no idea if this is the context of this particular project, but this is something we could work with. Here, I can infer which skills I would need daily, which skills I will need to have at least a ‘conversation level’ capability in, and which are the bits that are really not important, as long as I am versed in the concepts (e.g; I haven’t used VSS in over 10 years, but I am a strong advocate for quality software, especially good source control practices. So what if I prefer git?)

With just a bit of context, I think you’re far more likely to attract the right talent. And the right talent will be more likely to find you.

Though, charity+technology almost sold me.

Now, it’s time to wrap this up and head to candy mountain.


  • 0

5 small software development steps to a happier (future) you

Software development at times feels like a one-hundred-metre dash. At times it feels like a never-ending endurance race. At yet other times, software development is a whole series of short races, where you are blindfolded, spun around in circles before starting, and then criticised for not having already crossed the finish line yesterday.

Given the vagaries of software engineering, unrealistic and often contradictory expectations from colleagues, customers and (admit it) yourself, how then can you better prepare for those mad dashes? Is there anything you can do to ease your stress at these inevitable times of high pressure and short deadlines? Yes! There is! It is so simple, why haven’t you thought of it before?

Quit!

Unrealistic Expectations on Software Development Professionals

Actually, that’s probably not (usually) a good idea. So then, we need a different strategy. A strategy which will enable you to work more effectively, and improve your own (future) happiness. As a starting point, I propose taking some small steps which will set you on a better course. These steps won’t necessarily ease your immediate workload, and some of them will add a little extra to your daily process. However, the theory behind this proposal is that a few little changes in your development process can yield major benefits down the track. This is especially true at times of particular high stress. And the most relevant example of that is; when you really, really need to solve a major production fault last week.

Step 1: Write useful, comprehensive commit messages.

If you aren’t doing this, have a stern word with yourself and don’t ever (not) do it again. There is absolutely no point in writing commit messages like these (which I have seen time and time again);

  • “Work in progress” / “WIP” (thanks for nothing, guy)
  • “Fixed a bug with the text module” (what bug? Why did you “fix“ this bug in the way you did?)
  • “Changed SomeFunction() to return 0 instead of -1” (yes, I can see that from the diff, but why did you change this? What impact did it have? Why not return 123456789 instead?)

Joe Lencioni recently wrote a nice, concise piece on crafting great commit messages.

I try to be mindful that commit messages are for two audiences: code reviewers and future developers (including myself). I aim at giving these audiences context to understand why I made the decisions I made, which will help them make better decisions about the code I am committing today.” – Joe Lencioni 

A commit message does not need to tell me what you did. I can work that out myself from the corresponding diff. I (usually) don’t need to know how you did it either; assuming I can actually read your code and you haven’t made it overly complicated, I can probably also derive the how for myself (There might be exceptions to this where you’ve employed a particularly arcane, obscure or complex algorithm and some explanation there would be nice.)

I’ll re-emphasise the previous quote; the most important thing to focus on when writing a commit message is why. Why was the change required? Why did you use the approach you chose (and not another)? Why should you be allowed to ever make code changes again?

To keep our future selves (and our colleagues) sane, we need to focus on the why, because the what and the how are contained as evidence in the code itself. But I cannot determine from the code that you got some advice from a mentor, or found a relevant answer on StackOverflow. I can’t tell that you considered a more efficient, yet more complex, algorithm, but didn’t have the time to fully understand and test it. I can’t tell that you wrote this code expecting that users never use the letter ‘Q’ in their input. Leaving these sorts of hints for your (future) self can only ever help when you need to understand the nature and reason for some section of code.

If you can’t take a minute to describe your change in detail with a very strong focus on the why, or the commit is too large to encapsulate with a sensible message, then don’t make the commit. Take some extra minutes now, and save yourself hours later.

Step 2: Test your failure paths

Please don’t be one of those developers who test only the ‘happy path’ through their code and then proudly declare it “finished”. Nothing could be further from the truth, or more disrespectful of your colleagues and customers.

I have lost countless man-days integrating or testing someone else’s code only to find that as soon as I step off the tightrope of inputs and state this developer relied on, I have broken the system. Taking some time to test your own code for failures, both saves someone else’s time doing it for you (and having to raise defects against your work), and saves yourself time in the future trying to diagnose faults when they hit production and your inputs and states can no longer be guaranteed.

Save yourself the pain of live-debugging production faults in mission-critical systems , and assume that your code is going to fail. Become a coding pessimist. If you assume your code can fail, you’ll start to see all the ways in which it will.

Believe me, it’s easier and faster to fix now than it is once the customers get hold of it.

DontTestInProduction

Step 3: Assume a fail-early mentality as your default

This is a tricky one, and I’ve had arguments lively debates on this topic many times before. Some folks would advocate taking this approach to the extreme; “If anything goes wrong, crash”. Some folks will take the opposite extreme; “If something goes wrong, just ignore it!” (and maybe throw in a restart or retry). Some systems are explicitly designed around this latter mentality (for example the automatic Application Pool recycling in IIS which caters for the likely scenario of memory leak due to poor code or the .NET large object heap fragmentation, by hiding the problem on your behalf).

“Fail-early” to me means that you will take steps to have your application break, or at least alert somebody, as soon as an error occurs. You will not hide your errors in try-catch-ignore blocks. You don’t rely on a magic gnome to trawl through your production logs and let you know what’s gone wrong in the last 7 days.

There are clearly times when you’ll want to minimise the disruption from a particular error, and don’t want your users to see all your dirty laundry. My advice  here is treat “fail early” as your default setting. If you feel that this is not the appropriate way to handle some error, argue your way out of your default position. Start to think about the implications of hidden errors. Debugging downstream production errors due to invalid state caused by a hidden fault is the worst.

Step 4: Write helpful log and exception messages

There are very few scenarios in which “SomeMethod failed” is useful information when trying to diagnose a software fault. Generally speaking, exception messages should be designed for developers. Write an error message with your future self in mind. Ask yourself; “if I see this error message in 6 months time, will I know what it means?”. The answer to this question is surprisingly often “No, I won’t, but my code never fails, so this error message is just for posterity, really.”

Unhelpful error messages kill software developer morale

 

Why do exception messages not contain useful details? Good question.

Step 5: Read this book.

Although it’s over 15 years old, The Pragmatic Programmer contains reams of still-relevant advice and guidance on software engineering principles and better practices. I can’t say it any better than the highly-experienced folks who’ve reviewed this book in the past, so I’ll just quote one at random;

I would buy a copy, read it twice, then tell all my colleagues to run out and grab a copy. This is a book I would never loan because I would worry about it being lost.” – Martin Fowler

Just do it; you’ll learn so much. You’ll even re-learn ideas you didn’t know you’d forgotten.

 

Closing Arguments

Hopefully some of these tips will resonate. Try some of these steps once, just once, and when your future self realises the awesome work done by your past self, (s)he’ll smile.


  • 0

High Quality Code: It’s all in the details.

Over the years, I have worked with developers of all skill levels. And I have been a developer of many skill levels; from the non-developer rolling out barely-functional code to solve some pressing business problem, to the high-end experts who often seem to do no wrong. [I like to think that my quality/skill curve is continuously on the rise]
And over those same years, I’ve come to notice in certain talented developers, a particular quality, or perhaps it is a particular ability to focus and mentally sort the wheat from the chaff, spot that “needle in the haystack”, or simply quickly identify a likely cause (nor or at some point in the future) of software faults.

That quality is simply this; a high attention to detail. Whether it be a thorough commit message (i.e; something more informative than “fixed bug” or “WIP”), or an ability to quickly and accurately identify patterns in a problem or some code. These folks don’t just know what they are doing, they make sure they keep doing it. Attention to detail is the cornerstone of good process, and quality code. It is not;

  • Clicking madly through dozens of still-open windows to look for something you were working on this morning
  • Solving the ‘bug’ in its most literal reported sense, without considering wider ramifications or other likely symptoms of the fault
  • Leaving no information for your peers, or future self, to help understand why you made a particular change
  • Marking a bug or ticket as ‘resolved’, ‘fixed’ or ‘done’ without actually checking that it is fixed
  • Creating branches from whichever commit happens to be top of the current window
  • “Accidentally” committing changes that should never have seen the light of day (and doing this repeatedly)

I believe anyone with the drive and motivation can become a great developer, but without paying attention to what you are doing, and attempting to understand it, you will continue to founder, and potentially create more problems than you solve. Perhaps part of this is about slowing down; take a breath, and ensure that you didn’t just “get it done” but that you got it done right. In my book, 1 bug fixed correctly is better for everyone than 5 bugs which were incompletely resolved, or resolved in a way that just spawned new faults.

The most important thing to take away here is that whilst some people simply have some genetic or emotional makeup which makes them more likely to have an attention to detail, this very important skill can and should be learned. I have often seen the same symptoms in developers who do not seem to have the same attention to detail that makes a developer great. These often include;

  • Poor development habits – no repeatable actions in their daily work ;
  • Rushing to meet (real or perceived) deadlines, whilst failing to recognise that the mess you leave behind now will haunt you (and your testers, users & managers) tenfold in the future, and only exacerbate whatever deadline problems you are now experiencing;
  • Poor understanding of developer tools; (I have lost count a hundred times over of the number of bugs which would have been avoided by a developer simply paying attention to the inline code warnings from ReSharper);
  • Failure to write even the simplest of tests to validate the code;

Anyone can become great with the right motivation, and the right habits.

The only characteristic which cannot be externally overcome is a lack of desire to learn.

[As a controversial aside, a completely subjective comparison of dozens of past developer colleagues and acquaintances has led me to also conclude that attention to detail falls in direct proportion to the amount of mouse usage. A developer who relies on the mouse to perform tasks as trivial as a copy-paste, does in my experience, generally correspond to a low attention to detail, and a high bug count. Discuss.]