Careers – WTF is an API?

WTF is wrong with software!?!

I recently watched the excellent series Chernobyl.

It tells the story of a catastrophic nuclear meltdown, caused by concerted human incompetence and blind adherence to bureaucratic demands, even in the face of blatant evidence that what was being done was stupid, negligent, and dangerous.

After the accident, it took a long time to understand what had gone wrong, blame was thrown around wildly, and there were official efforts to disguise the causes of the accident.

Very little was done to try and learn from systematic failures, and to address the problems demonstrated by the incident.

As a software professional, it made me very sad how many similarities I can see between most places I have worked, and the Chernobyl accident and cover up.

How I feel most of the time at work:

The way software is written is fucked.

It is complex enough to be understood by very few people, and the process of writing it is consistently mismanaged, despite the fact that most of the pitfalls and mistakes made by literally every single team, have been pointed out, along with detailed steps for how to avoid them, since the 1970s.

Here is a pretend conversation that sums up the level of ignorance I have found in my professional life, as applied to another industry. (it is a metaphor you see):

Bob: Hello, I’m the new pilot for this here commercial aircraft.
Geoff (Bob’s employer): Hello Bob! Glad to have you on board. I hope you’re worth the enormous sum of money we’re paying you
Bob: Well of course I am! I passed your test didn’t I 🙂
Geoff: Well yes, you are right, you were very good at identifying the key differences between a jumbo jet and a bicycle, so I guess we’re all OK on that front

Some time later…

Emma(Bob’s copilot): Bob could you land the plane for me please. I need to visit the bathroom
Bob: Sure thing. One question, where do you keep the landing ropes?
Emma: What was that Bob? The landing ropes… What are they?
Bob: The ropes you use to loop around the lorry on the landing bit on the floor so it can pull you in and you can land
Emma: Bob, that is insane. What are you talking about
Bob: Oh, do you use a different system. I could use roller skates instead
Emma: …
Geoff: Hey guys, are you going to land this plane soon
Bob: Sure thing, just debating whether to use the ropes or the roller skates. I think we’re leaning towards the roller skates given the weather
Emma: …
Geoff: OK great, let me know how you get…
Emma: WHAT THE FUCK ARE YOU BOTH TALKING ABOUT!?!
Bob: Hold up there Emma, I’m not sure there’s any need to get angry like this
Geoff: Emma, what’s your problem? We really need to land this plane soon so can you please sort this out between you. What Bob said about the roller skates sounds sensible to me
Emma: BUT WE’LL CRASH INTO THE FLOOR AND DIE
Bob: I think that’s a bit extreme Emma, when I worked at Initrode we always used roller skates in inclement weather and we hardly ever crashed. We never took off either though… but I’m pretty sure the landing stuff would be fine

etc….

For another excellent summary of the type of madness you are likely to find in a software team, try this:

https://gizmodo.com/programming-sucks-why-a-job-in-coding-is-absolute-hell-1570227192

‘Ah but fortunately your example was unrealistic. That involved an aircraft, which could crash into the floor and kill people. Also nuclear reactors are totally different to coding. Software is just computers. It can’t do anything really nasty… right?’

No!

Not only is software fucked, it is increasingly responsible for scary things.

Defective software has recently:

Crashed two planes.
Exposed countless peoples’ private information to criminals. (This happens so often now that it’s barely even news)
Stopped customers from accessing their online banking for months.
Prevented doctors from accessing test results.
Grounded flights out of major airports.
Thrown people off electric scooters by ‘braking heavily’ under certain circumstances.

I found these examples from a ten minute Google search. There are probably many more cases, many of which are inherently difficult to reason about because… software is fucked!

To recap, software is often:

Responsible for scary things
Written by incompetent people
Managed by less competent people
Very difficult to understand for ‘non technical’ people
Shit

Which all combines to make me increasingly cynical and scared about my profession…

I have spent quite a bit of time reading about and discussing this phenomenon, and there appears to be a growing consensus, among both my peers and the wider community, that this cannot go on.

One of the potential solutions which is floated, in various forms is ‘REGULATION’.

Regulation!?! Yuck…

I’m not sure how I feel about it either… or what it should look like.

The cynic in me thinks that any attempt to regulate software development would add unnecessary overhead to an already slow and inefficient process, and would likely be mismanaged.

I also know that certain elements of writing software are very difficult to reason about, and that ensuring a program does what you intend it to do is hard.

That is to say, it is possible that even after doing your due diligence, becoming excellent at your craft, and testing all foreseeable outcomes, your code could still cause something horrible to happen.

In these cases I suspect assigning blame would be counter productive, whereas learning from mistakes could be very useful.

That said, the level of incompetence, and negligence I have encountered in some work places feels like there should be some legal protection in place, to make sure that development teams take responsibility for their code.

It seems totally unacceptable that testing and design is frequently shunted to the back of the priorities list, behind ‘hitting milestone 3’ or ‘drop 2’ or whatever that particular company is choosing to call their next client delivery.

If a shoddy system of development results in software which causes a loss of data, or money, or lives, then maybe someone should be held accountable.

That person should probably be paid a fairly large sum of money, for taking on the responsibility of ensuring that the software works (as many people in the software industry already are…), but equally, that reward should reflect the very real responsibility that has been taken on.

By which I mean that if it is found that the highly paid person that put their professional seal of approval on a product, did not adequately ensure that a system was put in place to develop robust and safe software, then they should be punished.

I don’t have a particular problem if your marketing website, or your blog has some bugs or UX issues, but almost all software I have worked on has involved user accounts and financial transactions, and is therefore responsible for peoples’ personal information and money.

That this type of software is developed within a system that rewards cutting corners, and punishes slow deliberation and robustness is something that I find deeply worrying.

Systems of development

One thing to emphasise, is that I don’t think the state of software is a reflection of any specific individual failings.

It is not a case of ‘shit developers’ or ‘shit managers’ or ‘shit clients’.

You might have noticed that I keep writing the word ‘system’.

That is because I recently read an excellent book on systems thinking and now frequently regurgitate snippets from it:

https://www.amazon.com/Thinking-Systems-Donella-H-Meadows-ebook/dp/B005VSRFEA

One of things that really stuck with me from this book is the idea that the actual outcomes of a system always reflect its true goals, or motivations, but that those true goals might differ (sometimes wildly), from any officially stated goals.

My theory is that in the majority of cases, software teams’ true goals and motivators are not robust software or a reworked and improved product, or a solved customer problem, and that is why these are rarely the outcome.

A team responsible for a piece of software is made up of a number of actors, or elements, all with competing goals.

You may have an external client, who you work with to define what the software should do.

They probably have a set of internal stakeholders they have to please, they may have a certain deliverable linked to their bonus that year, they may have inherited the project from someone else, and maybe they are trying to leave the company anyway, so they don’t particularly care about the long term success of the product.

The budget for the piece of software might have come about from a high level executive joining the client company and wanting to throw their weight around. They might not still be at the company in six months.

The team developing the software might have, intentionally or otherwise oversold what they can deliver and offered it for an unrealistically low price.

These mean that individual milestones or deliverables within a project are very important, as many of the actors within the system are depending on the outcome of them.

In a setup like the one above, the date the software is delivered on, is more important than whether it is shit or not, because more of the people within the system are depending on the date being hit, than on the software working well.

Individual developers within the team have a variety of different motivations.

Some are there just to take advantage of the elevated wages within the industry, and are content to turn up, do their job within the confines set out in front of them and go home.

They may or may not understand what they are doing, and they may make things so complicated from a code perspective, that reasoning about whether the product has bugs or not becomes almost impossible, but to be honest it doesn’t really matter.

As long as something is produced which looks and feels like something that was signed off and paid for, these guys have done their job.

These are the majority of developers I have encountered, and I don’t have a problem with them.

I do have a problem with the fact that the system they are working inside rewards this type of behaviour, but that is not their fault.

Others might want to actually deliver on the stated goals of the system, that is, roughly:

‘make a piece of robust software in the least complex way possible, such that it solves a clearly defined problem for the user of the software’.

This is quite a bit harder, requires constant reassessment of tools, techniques and design, and a commitment to mastering the fundamentals of your craft, across all disciplines involved, but in the medium to long term is definitely the way to go.

Amidst the background of all the other competing goals and motivations, these latter elements are likely to be frustrated.

Calls to slow down the pace of development in order to revisit the design of the product, or even to reassess whether the product is viable as a solution are generally ignored, as they will impede ‘deliverable alpha’.

In such a system, cutting corners is rewarded at all levels, and, again, this is not particularly anyone’s fault.

This would all be fine if it was happening in a bubble, but it’s not. These pieces of software are responsible for stuff that matters, and the real costs of these decisions are not felt by the people responsible for making the software, but by the users themselves.

In the above scenario, there might be a few raised voices and tense meetings, but it it very likely that everyone involved in making the software will be rewarded, as long as something is delivered on or around the date in the project plan.

Users may be lumbered with a buggy, slow, insecure program, or web app, but that is not really factored into the cost of development.

So what’s your point?

People responsible for making software are often motivated by many things other than making reliable, secure software that solves a defined user problem.

The negative effects of bad software are generally felt by users, not by those who put the software together.

In order to improve this situation, and to get better software that isn’t shit, it seems like there needs to be some sort of change to make the people responsible for creating software feel the effects of their shitty software themselves more keenly.

I don’t know what that would look like, and to be honest I don’t really have a point… All I really know is that I find my profession increasingly scary and insane, and that I’m not alone.

In defence of job hopping

(don’t be like Tim)

As a primer for why I think you should consider becoming a feckless, shifty, good-for-nothin’ job hopper, I offer the following cautionary tale.

I retrained as a software developer after a fledgling career in market research. Read more about it here.

My first job after my computer science masters was on a graduate scheme at a medium sized software consultancy, in a small university town, far away from the hustle and bustle of London.

I was excited to get started on my journey as a developer, and make up for lost time.

One of the reasons I opted to work for this consultancy was the shimmering promise of being able to work on many different projects, across different sectors and tech stacks, and to learn from the best.

The first few weeks were great. We were given in depth training in modern software engineering practices: automated testing, git, project management, scrum and agile, architecture and programming fundamentals. It was a dream.

Unfortunately, directly after this, I was tasked, along with a cohort of a dozen or so grads, with manually testing a true waterfall, death march disaster project.

There was an entire floor of staff dedicated to servicing this heaving, under-budgeted and over-sold behemoth, and after a few weeks of genuinely useful learning about the domain of the project, and gaining an understanding of the application, it became clear that any skills we learnt were not going to transfer into other programming roles.

At this point (and this will become a recurring theme), I began to panic.

I had abandoned a career which I had started to gain traction in, in order to become a software developer, and now I was faced with the prospect of leaving the job after a few years, with nothing but an in depth knowledge of a poorly written application to my name.

I was going to end up having spent 12 months at university and all of my money, as well as take a sizeable pay cut, to gain the professional experience that a high school leaver could get as a manual QA tester.

Three months later, I was still doing manual testing, and rapidly losing my mind.

Meet Tim

Around this time, while I was pulling my hair out and questioning all of my life decisions, I noticed Tim.

Tim did not share my concerns.

He joined as a grad and had already been at the company for a few years.

He had a PHD in a whizzy sounding hard science, and was clearly a clever guy.

However, he did zero programming; absolutely none.

What is more he didn’t seem to want to, despite his job role being ‘Software Engineer’.

He had been working on the death march project from the start, and was quite content to puzzle over spreadsheets and Word documents, doing the job of an entry level QA.

In some ways, this slightly zen attitude seemed admirable.

He also really did know how to do the job of a manual QA well.

However, there was a problem.

At the consultancy, Software Engineers (and Tim was a Software Engineer) were graded into bands.

As grads, we were band 1 Software Engineers.

As he had been at the company for a while, Tim had moved up a few bands.

These bands were partly used to decide on salary, but were also, crucially, used to dictate the price to hire us out to other companies for.

If a new project was being commissioned, the bid might include something like ‘two level 1 SEs and a level 3 SE’.

The point being, that a client expected a return for their money in the form of hard technical skills.

Tim, as you may recall did not have these technical skills.

After a few more months, Tim ended up being hired out to another project, as a Software Engineer level 4 or whatever he was at that stage.

Hurray! I was happy for him and also very jealous.

He came in with a big book on Java and sat poring through it at his desk, clearly determined to make sure he was up to the challenge.

Plot twist: Tim got fired.

That’s right, it turns out if you don’t acquire valuable skills that people want to pay for, the market will not reward you, and might even punish you, regardless of how good you are at your job.

Tim’s Java book remained on his old desk after he was gone, and made me shudder every time I walked past it.

What I did next

I ended up leaving the company very shortly afterwards, for a job at a tiny startup, with an even lower salary, in London, but where I would be able to get as much experience as possible in as short a period of time as possible.

I was at the consultancy for only six months, and was seriously worried about the effect that leaving so soon would have on my long term career prospects, but the gnawing horror about what had happened to Tim was enough to motivate me to hit the ejector switch.

This move turned out to be a good decision, and I stayed at the startup for a year and a half, inhaling knowledge and responsibility at a rapid rate, until I ultimately left for another job with almost double the salary, in order to be able to afford both rent and Tesco meal deals.

Since then I have essentially framed every career decision in terms of the experience it will give me, and whether that experience is something that the market will reward.

This greedy accumulation of experience gives me options, and has allowed me to be far more open at work when things aren’t working, and ultimately to not take any unnecessary shit, as I know that I can fall back on my skill set to find more work.

This feels great.

This tactic works particularly well in this industry because there is both a rampant demand for software professionals, and an under supply of good ones.

This means it is comparatively easy to stand out from the pack, assuming that you dedicate conscious effort to improving yourself in areas that the market rewards.

But this is immoral!?! What about the companies you’ve left in your wake

Somewhat… but I don’t think as much as you might think.

As I see it, software development is highly transactional in nature.

You pay me money, I build you a thing. You pay me more money, I maintain the thing I built, or the thing someone else built.

This lends itself very well to project based work, and has parallels in the building trade.

Building and engineering rely heavily on contracting work out to individuals and companies, who then build, or design the thing, take their money and move onto another project.

Framed in these terms, the idea that you would spend x number of years getting embroiled in a company mission, and supporting their long term goals at the expense of your own development seems misguided, and actually not beneficial to either of you.

I have always endeavoured to leave projects and companies in a better state than I found them.

As I specialise in one area of development currently (frontend), and one specific technology (Angular), I can join a company and be up and running in around a week. The training cost to them is very limited.

I always aim to deliver defined pieces of work to any company I’ve worked at, and have made sure to hand over what I’ve done to the rest of the team when I leave, including documenting anything I’ve done.

Recruitment costs aside (which have more than once not ended up being paid as I have left during my probation period), I don’t believe that my impact on any of the companies I’ve worked at has been negative.

I could be tragically misguided, but I believe that the way I have left companies means that I could go back to any of them if I really wanted to.

Why not just become a contractor then ya bum!

Fair point.

That’s actually what I’m going to do when my current job is finished in August.

Feel free to check back in a few months to see how that goes for me 🙂

If I’m honest, I am once again shitting myself.

WTF is Interview Cake

Interview Cake is a service that aims to prepare poor little coders for the stress and humiliation they are likely to encounter during a traditional technical interview, where candidates must solve problems using code, on a white board, often implementing common data structures and algorithms in order to do so.

For various reasons, I have never had to endure one of these interviews.

However, during my most recent/current job search I decided I would try and talk to some companies with a more rigorous approach to interviewing candidates.

I also have a niggling (occasionally crippling) fear of being found out as a fraud because I only became interested in computers later in life, and therefore must be a big fat faker who has only managed to get where he has due to luck.

And so, to assuage my feelings of inadequacy, I set about refreshing my very rusty knowledge of DATA STRUCTURES AND ALGORITHMS (the caps are because that is how I read it in my head whenever I see it on a job description).

After a bit of research I came across Interview Cake and decided this was the service for me.

Here is my unbiased and very limited review.

What is an Interview Cake?

Interview Cake is an online platform designed to offer an interactive way to familiarise yourself with common Algorithms and Data Structure related problems.

It does so via a series of short theoretical articles, and a decent number of practice questions, complete with hints and solutions.

The idea is to give the user exposure to the sorts of problems they will encounter during their interview, and to build up the mindset for breaking down complex problems and coming up with a working solution under time pressure.

For me it has felt a bit like exposure therapy.

I recently had a phone interview where I was asked to write a function in an online REPL, involving n and recursion and stack overflows and combinations and time and space complexity, and many other things that make me internally scream and want to run away.

Thanks to having spent the weeks/months before immersing myself in interview cakey goodness this was significantly less scary.

Would I recommend Interview Cake?

Yes.

It costs money, enough that it is a bit painful, but that has historically proved to be a good thing for me.

I am a cheapskate and the idea that I’m paying for something and not using it provides additional motivation to do the thing.

It is also expensive because it is good.

How good? Pretty good.

Why should you try it?

You get three free questions to see if you like the system, and if you pay for it and decide you don’t love it, you can get your money back.

Will it solve all your interview needs?

Probably not. I had to supplement it with videos, articles, blog posts etc., but for the practice side of things, it’s hard to beat.

WTF is a technical interview

A technical interview is an interview to assess whether a candidate is technically strong enough to join your team. A good technical interview should also give you a good impression of whether you could work with the person on a personal level.

Technical interviews are f**king difficult to get right.

As a candidate they can be stressful, bewildering affairs, involving whiteboards, theoretical questions, hands on coding and sometimes even trivia questions. There is very little standardisation and many companies do a bad job.

As an assessor it can be difficult to feel confident that you have properly assessed the candidate and ensured that they meet the technical bar.

Perhaps equally frustrating is a candidate making it all the way to a face to face interview, only for the assessor to discover that they can’t code their way through a basic FizzBuzz challenge. To avoid being a horrible person this results in having to sit through a painful half and hour to an hour of the candidate fumbling even the most basic tasks before an awkward ‘you’ll hear from us…’.

While looking for jobs I have been subject to a dazzling array of different technical interviews, the most heinous of which is the non existent technical interview.

NEVER work for a company as a software developer if they don’t make any attempt to properly assess you technically before you join.

If they are happy to hire you off the back of an enthusiastic buzz-word laden conversation, then they will do the same for others.

That means it is a total crap shoot as to whether you will be working with talented, passionate developers, or brainless monkeys who read some blogs about ‘Agile’. Do not take that risk.

What does a good technical interview look like?

My favourite interviews as a candidate have involved writing and analysing code, in an editor, on a computer.

My most successful interviews as an assessor have involved writing and analysing code, in an editor, on a computer.

See a theme?

So my completely biased answer is that a good technical interview involves a candidate writing and analysing code, in an editor, on a computer (you know, like they would do if they worked for you for instance…)

More specifically, for a mid to senior weight, hands on Angular developer, I have found the following interview pipeline/format invaluable.

1) Screen CVs. Exclude any without links to work they have done, either live websites, or GitHub projects. This is the number one indicator of whether someone is worth talking to. Then remove poorly formatted CVs or ones with obvious grammatical errors. Our discipline requires a lot of attention to detail, and a sloppy CV is a clear demonstration that this quality is lacking. Also exclude any with obviously poorly written code on their GitHub. Flags to look out for are:

Badly named functions
No unit tests
Poor documentation (no readme or one that is difficult to understand)
Code that doesn’t compile

2) Once you have screened CVs, put the ones you are interested in through to a phone screening.

3) Phone screening – Very quick, no more than half an hour. This should involve a series of conceptual and practical questions around your domain. In my case this is Object Orientation (specifically TypeScript), Unit testing, Angular core concepts (this is basically to weed out people who haven’t really used the framework before) and Git knowledge (this is a surprisingly accurate indicator of how much code someone has written in a professional setting).

4) If you like them and think it is worth taking two hours out of yours and up to two other members of staff’s time, schedule a face to face technical interview.

5) The face to face technical interview involves a series of short, hands on technical challenges, each no more than ten minutes long:

Debugging exercise: Hand the candidate a PC/laptop with an Angular application that is broken. Ask them to debug why it is broken and fix it, then offer suggestions for how to prevent the bug happening in the future.
Pair programming exercise: Give the candidate a PC/laptop with a partially implemented FizzBuzz service and some unit tests. Give them a brief and have them use TDD to fill in the rest of the functionality. Cut this off after ten minutes. By then you will have a good understanding of how the candidate writes code, how they explain their thinking, how they ask questions, whether they have written unit tests before, and how they approach problems.
Refactoring exercise: Hand the candidate a PC/laptop with a deliberately badly written piece of code on it. In my case I use an Angular component class which is directly making http calls, is filled with cryptic comments and typos, as well as buggy code and ask the candidate to assess the quality of the code, and suggest any improvements they might like to make. This will give you an idea of how committed a candidate is to writing good quality code. I’m ideally looking for people who are visibly upset by sloppy coding practices.
RXJS/reactive programming and streams: This is a conceptually complex area of the current coding landscape. To understand it properly a candidate must have a good appreciation of asynchronous code, and be comfortable with abstraction. Both are ubiquitous in our work. This is not a trivia quiz, we allow the candidate to ask any questions about the syntax we are having them use, and allow them to Google anything they want. Here we present a piece of code with some console logs in it and ask the candidate to predict what will happen when it is executed. We deliberately ask at least one seriously devious question, to see how they handle really difficult problems, and how they behave under pressure.
Responsive design: Hand the candidate a piece of non responsive sloppy CSS and ask them how they might make it responsive. The answer we are looking for is some variation of ‘use flex and do this…’.

After this we all breathe, and we move into an open discussion where we answer any of the candidates questions, and more thoroughly explain the role, the team etc.

The key thing that has made this process successful for us is that you gain a real appreciation of how the person will be to work with, because you essentially work with them in the interview.

It also has the added benefit that you are able to sell yourself and your team to the candidate, as most are seriously impressed that you have gone to such lengths to properly assess them. The tests are also all quite fun, and even candidates that don’t perform well have said that they enjoy the experience and will go away with a good impression of your company.

Having had extensive experience of interviewing from the point of view of the candidate, I believe that this is a pretty effective and relatively painless way of assessing a candidate.

What are your thoughts?