Too often in software engineering people are too quick to focus on the latest technology and reticent to develop their knowledge of the fundamentals. I suppose the reason for this is to build marketable skills. Recruiters and employers tend to focus on the technology their hiring managers (often other engineers) ask them for, which is usually the latest shiny thing and so the cycle continues.
Let’s start with describing what I mean by the fundamentals with some examples. The first set are typically the things you’d learn in a good Computer Science undergraduate programme. Examples are:
Operating system design
The next set are generally good things to know for any software engineer but aren’t always covered in mandatory modules in CS degrees. Things like:
Low level computing
I could go on but you get the idea, you won’t regret learning these things, whatever you go on to do in software engineering you’ll find them useful, possibly essential. They will help you learn the latest shiny technology more quickly because you’ll know the building blocks of such things.
There’s more too, if you skip learning one to two cycles of shiny things you won’t notice it in a few months or years. Does anyone regret not learning grunt, then gulp, then webpack, not really, you just need one that works and nothing too bad happens if you skip one. Have little to no knowledge of networking or algorithms you’re severly going to limit what you are capable of.
So, should you avoid learning shiny new technology altogether? Absolutely not! Whilst learning those technologies you’ll pick up reusable skills for other tech, but guess what, those reusable things are the fundamentals. Thus if you want to accelerate your speed or learning, reduce those difficult learning curves, make sure you’re spending enough time looking at the basic underpinnings of computer science, they’re so important.
This topics comes up a lot: “how do I do authorization for my service architecture?” or if they are hip with the kids “how do I do authorization for my microservices”. The answer to both is the same…
Firstly some definitions:
the process of confirming, to a level of certainty, a user is who they say they are. Often this is done with a username and password pair, but could be done with a certificate, PIN, token, fingerprint or anything else.
the process of making sure that people can only do the things they should be allowed to and see the data they should be allowed to.
The Authorization-as-a-Service Anti-Pattern
Now at first guess it might make sense to have a service that does authorization. Why not, you can put all that complexity in one place and not worry about it anymore, safe in the knowledge that all that difficult authorization logic is encapsulated.
Trouble is when you add a new feature in an other service you need to make a change to your authorization service, to enforce the correct access to that service. It turns out everytime you make a change to any other service 9 times out of 10 you are then making a modification to the authorization service. This quickly gets tedious - it smells wrong.
Say you decided to live with the inconvience of the above double modification problem, who do you get to maintain and run the authorization service. You could have one team do it. However fairly rapidly they are going to be inundated with change requests, because every change to any other services needs a change to their service (most of the time at least).
The other option is to allow the teams who require the change to make the changes to the authorization service themselves. Trouble is then you have many teams churning a service’s code base that they don’t own then they don’t feel, indeed literally they don’t have, ownership and that’s a recipe to declining quality.
On top of all this, the releases of the authorization service needs to be sychnorized with all the other services that have been modified recently. Pretty soon you are in a stop-the-world type release process where every service in your estate needs releasing at the same time. The logistics are a nightmare.
The simplest solution to the problem is to have authentication as a service; that is proving I am who I say I am.
Once you have the ability for a service to determin within a level of certainty that a user is who they say they are, then you can do authorization in each service. What better place to have the complex logic of who can do what than in the code that does the what.
For example consider a service that is responsible for providing access to a financial trading platform. It allows brokers to buy and sell a stock. Now the service might be aware that certain brokers can only buy €100k of the stock each day, it keeps track of this, because that’s what it does, rather than reaching out to an external service to ask, it has the information right there, it knows who you are, what you’ve bought and the rules for how much you can buy - it’s cohesive. Now say you want to change it so that brokers can only buy stock Monday through Friday, again all the information is there. There is no need to go anywhere else.
Perhaps you might write a library, a shared object, dll, jar or npm for it that others can reuse. JaaS and implementations thereof are a good example of something approximating a good design here, but don’t create a service, you’ll regret it.
Developers, software engineers, smart people, people have needs, these needs differ and certainly differ in weighting from person to person but I think the below lists the key desires of most. I, of course, can’t speak for everyone, I would however, like to be as complete and thorough as I can—I’m a techy, it goes with the territory—so please contact me if I’ve missed anything. Whilst this post is focused on software engineers it could equally apply to any profession that needs brains and experience.
I believe strongly that software engineering is a creative process. Not only is it a creative process like painting, making a photograph, giving a speech or product design it also requires large amounts of technical expertise. That’s it’s, an inate gift and hard earned knowledge and then, if that weren’t enough, determination to be successful and with the right environment: successful with others. These people are therefore incredibly hard to find, these are the people that will change the world.
People like these, people like you, can change the world, people like you have changed it, it’s sappy, I’m sappy, I won’t appologise. Below are some notes for your prospective employeers, custodians of your working life whilst you let them, I hope I can make a reasonable job of it.
It pains me that I have to even say this: engineers deserve respect, they do a extremely mentally challenging job and the good ones, they’re smart, damn smart. When you treat them like children by taking away decision making power, coating their days in pointless process due to lack of trust or, worse of all, not listening to them then you do everyone a disservice. You won’t get even a tiny fraction of the benefit you could get out of them.
“Imagine what you’ll enable people to achieve if you believe in them”. — Dan North
So do it, believe in your people, let them know by showing them respect.
Listen to them
Listen to software engineers, they have opinions not just on software engineering but on everything from product developement, through personnel and on through P&L, they may not be right all the time but if they are as smart as you want them to be then they’re going to be right a whole, at a minimum they’ll give you new angles. Listening is the foundation of respect.
Other developers like them
Software engineering is a team exercise, of course from time to time we need alone time to think, but most of the time bouncing ideas of like minded people is going to be the best course of action. Be it pair programming, whiteboarding new ideas or discussing the latest technology over lunch, great software engineers like to spend time with other great software engineers, it makes them happy—fundamentally happy.
Remember software engineers, especially open source developer are ahead of most in terms of interacting online and therefore being part of a team doesn’t need to mean physical proximity, it could be via hangouts, hipchat or even good old IRC.
Fundamentally they want to work with other smart people with a common purpose, best make that common purpose yours.
Other smart people
Great developers want to work with smart people in other disaplines too. This could be product development, sales, marketing, procurement or personnel. It helps everyone grow, so unless you are running a production line (and why wouldn’t you automate that?), then make sure you only hire the best people throughout your organisation. Perhaps I’m stating something obvious: hire smart people—what I mean is hiring is the most important thing you do.
Access to tech conferences
Even when you get the best engineers working together in a team, with the best professionals in other disaplines, the knowledge and thinking can get a little stale. Engineers, we like to get out and meet other likeminded souls who haven’t been our team mates for years. Some of us even like to speak at conferences (cough), firstly because it feels good to share information, be part of something bigger and secondly it’s because it provokes a conversation. Let your gals and guys out once in a while, pay the airfare, put them up somewhere nice and let them meet other smart people.
Companies that talk about their (cool) technology.
This goes hand in hand with the conference attending, if you speak about the great things you are doing then people are going to want to come and work on them. Smart people want difficult challenges and they want to solve them in smart ways and then they want to brag about it. Smart people who want to do this and can’t are on the constant look out for those that will let them.
One word of caution, if you technology isn’t great you’ll do more damage than good try to palm it off as good. Either be honest and speak to the challenges or don’t bother.
Freedom to express their views
The best engineers tend to be opinionated (the reverse doesn’t necessarily apply) and so by definition they like to put forth their opinions. If you restrict them from doing so you’ll firstly make them sad and secondly deny them the chance of being challenged and finding out there was more to learn (there always is). Also be prepared for this taking multiple forms, for some this could be a posting on a message board, other it might be an empassioned monologue during a meeting but best of all it might be a commit to github.
If your software is closed then it makes it very hard for your software developers to engage with the outside world of software engineering in a meaningful way. It also takes away their ability to show off what they’ve been doing. Smart people like to show other smart people how smart they are from time to time. They do it a little for their ego but mostly to start a conversation with other smart people and learn.
By putting your software out there you’ll show the world that your company is made of smart people too and you’ll capture their attention, perhaps they’ll help you write your software, perhaps they’ll become a colleague (perhaps they’ll be your boss [ssshhh]).
Hardware & software they need/want
I’ve lots count of the times I’ve heard engineers lamenting being fobbed of when asking for better equipment. The logic goes something like, we have a standard build, it will only work on this configuration and it’s good enough for the guys in legal (no offense) so suck it up (of course most budget holders will put it more nicely than that but the engineers will hear ‘we don’t value you’).
Just stop it, let your software engineers pick any laptop, desktop, mobile phone or flux capacitor they want and as long as it doesn’t cost the price of a new family car every year, go with it. It will make them more productive, happier and ultimately it’ll save you money in time spent discussing it—don’t believe me, want a business case, tough, you won’t get the best techs to work for you if you don’t.
Safe environment for innovation
Everyone should be allowed to innovate, it shouldn’t be scheduled and it shouldn’t be the sole perview of a few chosen individuals, if you want to spend time looking into Huffman Coding and using it to increase data read times from disk then that’s what you should do—who else but the smart person thinking about that problem is going to have a better opinion of whether it’s a waste of time or not? Bear in mind it might not be her ‘job’ to be worrying about data density read speeds, go with it, what’s the worst that could happen?
A career path
It’s no longer good enough to force your best engineers to be people managers once they hit a certain pay grade, a few might want to, let them, but most won’t: so stop it. Give them something else to aim for that gives similar benefits: reward package, pension, car, bonus, blah. What else is there to aim for you might wonder, if it not a big team and a huge budget? It’s probably access to hard problems, large amounts of hardware, time and people but, you know, ask them, they’ll tell you.
Normal people dislike office politics, engineers dislike them even more, make sure you have an office that is focussed on your purpose not playing silly beggars; enough said.
Have the absolute bare minimum of process that makes you feel comfortable, see how it feels and then remove some more, after about 10 iterations of this your probably where you need to be. The more process you have the harder it is to change and technology is all about change, therefore the more process you have the less likely it is that you’ll have great technology.
Appraisals are mostly theatre, make what happens useful and remove the rest. Make sure that someone that understands what the individual does leads the appraisal and don’t leave it more than a week to give positive or negative feedback. As a great boss of mine once said, appraisals shouldn’t be a 6 monthly surprise. There are entire libraries of books on this subject but that’s about the size of it. Everyone wants to know, objectively, how they’re performing, even or perhaps especially the best performers suffer from imposter syndrome, so let them know they’re doing a great job and don’t make them fill in a 10 page form every 6 months.
A company with a purpose
The worst possible thing is to have no meaning. A recent article talked of gifted people being plagued by feelings of meaningless, more than those less able. If your organisation has no common purpose then talented people are going to feel it more keenly. Have one goal, communicate it, then communicate it again, when it doesn’t happen, ask why, make changes, involve your engineers and keep communicating it. Did I mention you need to communicate your common purpose? What is it? Write it down, write it on the wall in spray paint, write it on every wall. If that purpose doesn’t interest them, shake hands and move on, if it does you can guarantee they’ll be fired up to know that everyone cares and that you care.