Beyond Naughty Processors.

meltdown-spectreThe world is abuzz with stuff about the Intel bugs – so much so that Meltdown and Spectre are explained by xkcd better to the masses than most technical articles. It’s as if the world woke up and saw a small bit of what can happen within computing systems and, unfortunately for Intel, gets branded with Intel.

Did I mention Intel? Oh, don’t worry, it’s not the only brand that is getting sucked into this. Apple’s vulnerability to Meltdown and Spectre has also been admitted.

The potential is serious. But then, having seen code over the years that allowed pretty much the same thing– clearly, I fixed it where I saw it – I’m not as disturbed as the people presently flailing their arms until the next thing comes along. People will forget soon.

I’m not a chip designer, but the overall problem is pretty close to the Software Engineering issues the world presently faces.

People, generally – I still think of them as users – don’t care too much about technology. I’d say the same about management, too, in most companies – in the early 90s I said, “Management doesn’t know there is a fire until the flames are licking their asses.” This held true in just about every company I worked with until 2016, when I opted to start early on other endeavors to mitigate the risk of being an X-gen Software Engineer in a market that wanted millenial code monkeys.

Here’s the dilemma: Writing good code costs more time and money than most companies want to dedicate because, cyclically, they need to show profit faster because of increased competition in the sector.

Code monkeys are appreciated for fixing the bugs that they created in the first place, Software Engineers aren’t appreciated for the bugs that they keep from being introduced. And so, HR is always looking for code monkeys instead of true software engineers.

Venture capitalists and financiers care more about the commodity of  Intellectual Property than the service of Intellectual property, mainly because people find it difficult to think of copyrighted or patented – or even company secrets – as a service. We live in an age where information and processes do not stand still; it’s not that there is Intellectual Property anymore that you can sit on – it’s that there is Intellectual Property that you have to build on.

But Intellectual Property as a commodity is how trading is done – like the statistics on a baseball card (for the Americans reading) of a living player that will be outdated the very next game. Copyrights, Patents, Trademarks, Trade Secrets – these are snapshots in time. They are not as fluid as what they represent. They are bureaucratic stop gaps to elicit profit, which has worked for a very long time because they were designed to. But what they were designed on is changing faster than this bureaucracy can accommodate.

So all of this leads to design flaws because the designs can’t possibly cover all permutations of how something can be used. It’s getting better, but by getting better it gives a false sense of security that makes the more elusive problems worse for our systems. As I wrote to someone querying about whether foreign processors would have the issue or other issues, I said, “Nothing is secure. Act like it.”

The world is changing more rapidly than the people changing it can keep up with.

Let that sink in.

And then, if you suffer some history, you’ll find it has always been this way. The future has a mind of it’s own.

The only way to mitigate things – the only true way – is for people to be more conscious of what they use. When I was growing up, because of how I grew up, I picked up the habit of understanding at least the basic functionality of everything I used. If it broke, back in the days before the Internet, in a ‘developing’ country, I had to fix it or throw it away.

Now, landfills are filled by slowed phones and antiquated technology. If I’m a dinosaur, I see the meteors and appreciate keeping things around a while when others are quick to buy the next new (untested) thing.

It’s a brave new world.

I’ll be in my garden.

For Those Entering Tech.

algorithms fearI had a recent Skype conversation with someone working at a company that I had done some contract work for. I suppose I went in knowing how it would go and for a bit of closure – it was the same old story. Contractor does work for a company, contractor does what was required faster than company expected in the hope of a more permanent position, company ends contract.

Someone messaged me on LinkedIn, looking for sage advice because of what I had written – thinking me sage when I am only greying, thinking me wise because I’m good with a keyboard. And all I could come up with this was:

It was a salt trap. 

One of the good things about taking myself out of the job market is to write, unrestrained, about career-limiting topics – mainly because the career is over because I decided not to continue falling for the salt trap. I decided it was time to shift my future, so I did and I have no regrets – though the adjustments are still happening.

My experience in the Software Engineering market spans pre-Internet to last year (and whatever I fiddle with these days). I’ve only worked for one true multinational, and I’ve done work or worked for companies that have disappeared in the churning of economies. Most of the code I wrote – if I called it ‘my code’, intellectual property lawyers would cringe – is not in use. I’m almost sure of it. Contributions to projects deceased.

Sisyphus on a conveyor belt rolling against him. And the project managers and upper management keep singing,  “Keep pushing, folks.” 

In this, I suspect, I am not alone – I suspect that people around my age in the industry have done their time in the Code Mines of places long forgotten. We’ve been through bad economies, through tech bubbles and their inadvertent falls. We’ve seen the rise and fall of languages and frameworks, of business practices that range from asinine to outrageously lucky – rarely solid.

So what is this all about? Oddly enough, it’s about fear. It’s the rare tech company that is built to last; most seem to be built to get money in a tech ponzi scheme – from venture capital to buyouts. The big picture is lost, leaving some really smart people writing some really good code that will not last, that isn’t intended to last, that is meant to get someone else to their own version of success.

Disgruntled? You bet, though I have taken the Path to Gruntlement. There are so many young ones in technology trying to get their street cred, fluffing their resumes – is it appropriate to fluff your own professional persona? – competing against each other like crabs in a barrel, necessarily antagonistic in a market that would do better with more collaboration. Or is it the natural antagonism of tech people? It’s hard to tell.

So my advice to those entering the market is that the market is not the few tech companies you are unlikely to work for, it’s the churning primordial ooze of failures that makes the market – and you will, at the least, have to weather that – if you’re lucky, if you’ve had a good start or get the right opportunities, know that these can be fleeting and that it’s easy to slide back into the ooze. Accept that it’s not going to happen the way you want – or the way that anyone else does, anyway.

Learn and move before they disappear.

Find recruiters that don’t suck. If you’re getting cold called at work by recruiters, block their numbers. Professionals would send you an email first.

Find managers that don’t suck. I could write a book about that. Maybe I should.

And keep pushing until you tire of it – and recognize when you are tired before your body figures it out.

How To Hire A Software Developer (2012)

Drupal Code MonkeyOne of the fun and interesting things that has been cropping up with some job interviews for contracts and employment is the potential employer wanting to know whether someone is actually a good software developer or programmer. The trouble is that there are flaws in just about any way of doing it. Having been on both sides of the desk, I’ve helped hire good programmers and bad – even over the phone – and I’ve interviewed for positions that fit me like a glove or didn’t.

Here’s some things I’ve seen recently – but if you want, just skip to the ‘How To Hire A Good Software Developer‘ part at the bottom.

How Did You Learn?

This is a legitimate question for anyone without a year of experience – to be safe, lets say 2 years. I recall interviewing for a position around 2003 in Trinidad and Tobago – a position for some oil related company about a VB 5.0 position – and I was asked this. With close to two decades of experience on my resume at the time, I explained that it was learned on the job and that I had references on it. But that’s not what they wanted. That people learn stuff in the real world seemed to escape them.

Recently, I applied for an Open Source Consultation position. It’s a natural position for me, really – open source advocacy, familiarity with open source projects and not just how the code works but the communities around them as well as their directions. I’ve even spoken at 4 open source conferences I can recall off the top of my head (not counting smaller group meetings). But somehow, someone in that company thought… If they don’t have a degree in something, even underwater basket weaving, they can’t do the job.

Does a  degree actually help with programming? I’ve seen it go both ways. I’ve met great software developers – yes, some better than me, more than I might like to admit – but whether they had a degree or not wasn’t material. I’ve also met some really poor programmers who had great GPAs. Poor programmers without degrees don’t exist. Why? The College of Experience is not as easily gamed.

Degrees don’t matter unless it’s an entry level position – and entry level positions are high risks for both employers and employees anyway.

Code Samples

There are a few companies out there that ask for code samples and, really, that might be a good way to judge how someone wrote code when they wrote the code – with or without help on a project that may or may not pertain to what the potential employer needs to have done – as opposed to what they may actually advertise for the particular position.

Another problem – one that I run into – is the ever present NDA. Believe it or not, there are companies out there that don’t seem to understand that work done these days is almost always covered by an NDA. Unless you contribute code regularly to open source projects, this may be a pit of despair. My thought: If the hiring company doesn’t understand NDAs, maybe they haven’t worked on things that work with business intelligence.

Fizzbuzzed.

When Jeff Atwood wrote ‘Why Can’t Programmers… Program?”, the Fizzbuzz test became popular with employers unable to design their own tests. A mind familiar with solving academic problems does well with these things. Not all programmers are familiar with solving academic problems. Recently I was asked to write some code that showed the first 10 prime numbers – and in trying to recall the first 10 just as a quiz for myself, I missed a few. I did do the code on the whiteboard, but hey, the point is – the muscles exercised are the strong ones. In programming since the 80s, this was the first time someone thought the prime numbers were important enough to write code for.

Code testing is subjective. This is as it should be. But if you want to do some code testing with a candidate, why not make it subjective to the job itself? Factor in that problems as famous as Fizzbuzz can also be crammed for. Really. Just Google interview code question. Rather than throwing Fizzbuzz or an analog of it out there, why not have a test that relates to the business in the position being filled? That might be a good test. In fact, that should be the test. The candidate should be able to tackle a problem that relates to the position being filled.

What’s special about the position? Test that. It typically includes the skills that you need tested anyway.

The other part of this deals with attitude. Throw a real problem at a real software developer and you’ll get to see how they really think, code and how they approach that problem. People don’t always approach the same problem the same way and that has benefits. The interviewers have to be able to understand that. When trying to make a good first impression sometimes people don’t.

Personality

Personality tests are used here and there and the results are almost never released to the candidate. As someone who has tested consistently as an INTJ1 for decades, I’ve made it a hobby. To an INTJ, a hobby is a serious thing. I don’t claim to be an expert on personality tests but I’ve read a lot on the topic and have taken a lot of tests.

Some things to remember about personality tests:

  • They are snapshots. A personality test is affected by ‘where’ the person is when they are taking the test; stress and other factors change the results.
  • They are incomplete.
  • They create a great industry for people who make money testing personalities and telling you that you need to do them.

How To Hire A Good Software Developer

So here it is. The magic of hiring a good software developer can be summed up in point form.

  • Why do they want the job? Save the ‘World Peace’ beauty contestant speech. If a software developer has everything you need for the position, they can’t grow. A good software developer grows. If a developer has nothing to aspire to then they aren’t a good developer.
  • Do they understand your business? A developer who understands the business, even in the broad strokes, is better than someone who can do the Fizzbuzz test in one line (yeah, it can be done in one line in at least one language I know of). Some of the hardest and best interviews I’ve had involved ‘walking the floor’ and being shown the business and the role the developer would be playing within it.
  • Can they problem solve? The best way to check is to go over problems related to the business. You could hand them a Rubik’s cube – if your business is about solving Rubik’s cubes. You could have them write code, too, but try to make it at least related to the job.
  • Interviews can be nerve-wracking for people on both sides of the desk. A good interviewer harnesses this and can choose to disarm or build pressure – typically both. This is why some companies play ‘good cop, bad cop’ in interviews – but the interviewer has to understand people to do any of this. If you’re pulling someone kicking and screaming away from their keyboard and their social skills are limited to Internet interactions, their body language will likely throw things off. If the interviewer doesn’t interact with people on a social level very well… things can go bad.  And if the software developer being interviewed is a social misfit, the question is whether this misfit will fit in with the other misfits.
  • Curiosity. Good developers are curious.
  • Thoughtful – not in the ‘brings flowers to funerals and weddings’ thoughtful, but a good developer will sometimes take the time to think through something rather than rushing off on tangents. Rushing off on tangents is typically what less experienced developers do.
  • Confident. This is not to be mistaken for false confidence.
  • Interested. If they’re yawning, they’re not interested.

Clearly, everyone will approach hiring a software developer differently and it’s no question that they get different results. The trick is not finding the perfect software developer.

The trick is finding the right software developer.

Feel free to comment!

1Myers-Briggs Type Indicator and Socionics, thank you very much.

The Reason Why Your Tech Employees Are Leaving

SH-dinky-I-quitThere’s a bazillion articles out there on employee retention the last time I stopped counting. Tech employees are slightly different. Without further ado:

1: They’re Unhappy.

Tada. This is why people leave.

Tech folk are a bit like cats, and herding cats is not an easy task. People want different things. If you don’t know what the individuals want, you’ve already identified your first problem.

You can’t and should not please everyone.

You might be amazed at how easy it is to retain employees if you simply listen and react appropriately – and bear in mind that the rest of the team is paying attention and taking note.

1a: Hot And Cold

If there is no respite, if it’s a matter of going from one thing to another, running hot on projects behind schedules and cold on new things, you’re encountering basic physics. Constant expansion and contraction is not good for anything, particularly people. The larger the gradient between hot and cold, the more likely you’re going to lose people. This is part and parcel of a Culture of Fear.

1b: Unfair Treatment

You might like to think that you’re treating everyone equally, but your team might see it otherwise. If one person throws a tantrum and gets what they want – be it a supply of Coke products or an office – expect the rest of the team to either learn the lesson or begin disapproving of management (if they haven’t already).

Further, if you ride one person hard but let another get away with murder, you’re asking for it. While you may have higher expectations of one or the other, inconsistency in how the team is treated fractures the team.

1c: Rewarding Jerks

When you reward someone who is not a team player and is constantly creating friction, and when they get away with just about anything, it’s a matter of time before either (a)people start acting like jerks or (b) they pack up their toys and go home.

If you find yourself in a position where you have to pick between two employees, it’s already too late and you should be wondering how that happened in the first place.

Bear in mind, treating a jerk and someone who is not a jerk the same when dealing with an altercation gives the jerk the high ground. Do that consistently, expect the non-jerk to walk. Maybe just spontaneously one day.

If you can’t identify a jerk, you have much larger problems. If you like the jerk, you’re a jerk – and if you don’t like the jerk and keep the jerk, you’re a jerk. Embrace it and stop reading here.

1d: Bad Priorities

You (hopefully) hired smart people, and while you may not show your cards, people can discern bad priorities when they see them – or worse, they can believe that it is a bad priority because your organization lacks the transparency for them to see it as good.

Tech folks generally like to feel like they are doing something of worth.

1e: Not Involving the Team in Big Decisions

This doesn’t mean that the team has to agree on everything, but if it’s a decision on how something will be done across the team, get input from the team as a whole. And if you have people who steal oxygen from meetings, make sure they don’t monopolize the time or frame things such that it’s their way or not.

1f: Lack of Growth

If you’ve hired people who don’t want to grow or help the team in greater ways, you hired wrong and you have larger problems. This is not to be confused with the Empire Builders – those that harden their position and are constantly finding ways to make themselves relevant in places where other team members might be greater assets.

1g: Influence Issues

Someone who has developed influence in your organization by hard work and perseverance is an asset, and while they will likely be resistant to changes you want to implement, if you leave them out of Big Decisions (see 1e) you may well be shooting yourself in the foot. If they don’t get upset, or suddenly stop becoming upset, they’re on their way out – which may or may not be good.

If you have someone who has accepted increasing responsibility, knows how things work that you don’t understand and has gotten in front of problems… you may not appreciate them because they’ve kept the flames from creating the tell-tale smoke signals. Unfortunately, when you smell smoke after they leave or just before they leave, it’s too late – so pay attention to how people get in front of problems.

1h: Money

Yeah, money had to make it in here somewhere but I purposefully left it down here as the last one. Why? Because if people are having trouble making ends meet they WILL look. If your tech people are having that problem, that’s a big glaring issue you will pay for if you don’t pay for.

Money isn’t as much of an issue as people make it out to be – the people who just want more money will likely leave anyway when they get a better offer, and you might be better off without them.

By the time someone starts comparing salaries, they’ve already decided to start looking. Even if you pay them more, they’re likely to leave anyway – except the unicorns. They do exist and typically negotiate more than money.

This post also made available on LinkedIn.