Or is it? I don’t want to start the new year with a negative post but the ongoing state of software is unsustainable. It is also unfair on paying users to expect them to put up with it. Products are being released that are unfit for purpose, insecure and unreliable. This is at a time when people more than ever have bought into the tech dream. They are sharing on social media and managing their life with a large number of apps. Everything from managing their shopping lists, consuming their entertainment to family planning.
And yet as an industry, we expect them to put up with terrible UI’s, bugs, breakages and security breaches. All the while we expect them to continue paying a subscription fee so we can build more features for them to endure. As users, we never ask for our subscription fee back if it goes wrong. Why? If you are paying for fine dining and your food was under or overcooked, you would complain. If you arrived on your holiday to find that your hotel was a building site, you would get your money back. So why are we happy to accept broken apps?
How many of you can relate to what Scott outlined in that post? Not so much the actual software and services that were breaking. More the common thread that every app you try somehow has an issue or lets you down.
In a similar approach to that article, here are the stupid issues I have had to deal with this week:
Notion. On mobile takes three attempts to open and takes nearly a minute to load the first page. On any platform, it will not allow me to “Duplicate” a page with a lot of subpages. It tells me that the page is too big.
All 4 mobile app. It stopped playing every time it needed to play a commercial.
American Airlines Payment Page. I upgraded some seats and wanted to give them £300. Their payment page will only allow you to enter an American address. A preset state and required zip field blocked me from doing so.
Chromecast. It never streams a whole film without failing even though I am casting from a Pixel 3. It’s not just my phone either. My wife has a Moto G and my son an iPhone and they both suffer the same.
My Fitness Pal seems to show ads fine but when you are searching for foods to log it regularly causes the app to stop working.
Station. Adding many Google accounts doesn’t work. It looks like it has worked but it confuses the accounts when you try and switch between them. Also if you keep pages open to read later (their core USP) then say goodbye to your RAM. At one point this week it was eating 45% of mine.
Bluetooth. Four sets of headphones and one Android phone. Every time I turn on a pair they can not reconnect without repairing.
Visual Studio Code. On Manjaro, every time I try to use it after hibernation the UI breaks. I get random UI elements all over the screen and have to restart it.
I will stop now as I am boring myself.
So why have things not improved since Scott wrote his piece eight years ago? I am not alone in thinking about this. Nikita Prokopov recently published a great article on Software Disenchantment. In it, he talks about badly designed, slow, untested software. He also talks about why companies allow their products to go out in such an unfinished state. It’s a very worthy read.
As an industry we have some growing up to do. I can not think of another professional group of people that behave in this way.
We need to start by focusing on users. Every user is unique but we treat them as a defined standard. We give little thought to users that are older or who have disabilities or accessibility issues. Teams spend excessive time focusing on creating UX journeys that result in conversions. Few teams spend equal time on defining enjoyable experiences. Nor experiences that are enjoyable and seamless for all their users. User-centred design is key to a successful product. Great UX experiences will result in conversions.
We need to realise that while MVP’s are a perfectly good idea they need testing. A common thread in the startup mentality is that a developer can do everything. Build it quickly, release it and the users will come. We have seen this with the idea of Devops and it is not working as sold. Great developers write code and solve problems. Great testers ensure that what developers produce works and are fit for purpose. Great Infrastructure teams ensure it is working in an optimal fashion 99.9999% of the time. Teams need to have the right balance. It’s not right to expect one or two people to do it all.
The tools used for developing products need improvement. It is over 75 years since Plankalkül was designed. That’s a long time for such little progress. Languages and stacks today vary in quality and achievable productivity. They all still allow you to write code that results in basic errors. Why? Vast numbers of programs are CRUD based database front ends. Why is this not a solved problem? Why do we focus on disagreeing on the difference between language X and Y? Or the difference between object-oriented and functional programming? Let’s set about building a common framework of solid, risk-free tools that enable fast development of common functionality. Let’s also focus on making that framework work across the most common OS’s and hardware.
We are lucky enough to have some immensely intelligent minds within our industry. We also have a large number of people that do care about users and stability and experiences. Let’s embrace those people. They don’t want to slow down projects. They don’t want to prevent revenue generation. They want to be proud of the technology they build and they care what users think. Their knowledge, idea’s and passion will result in far more happy users and revenue as a result.
Think back to the last website or application that made you feel surprised or happy from using it? Now think about the experiences in the last few weeks that were negative. Is it not time to expect more of the former?
I am keen to hear your thoughts around the current state of affairs so please contact me via twitter or email.
This is the last post I will write before Christmas as the end of the year has snuck up on me. As I have tried to in previous years I wanted to write a reflective post as 2019 has been a big year for me.
As far as this blog goes, I have managed to hit my target of writing a post a week. Apart from the week’s I have been travelling with the family I have posted every week. Looking back through the posts, I have not had the chance to share so much technical detail. A lot of posts have been brain dumps of thoughts of issues I had been dealing with. That summarises what I have been dealing with for two-thirds of the year. I plan to move back to writing more technical howtos and articles for 2020. I also need to promote the blog more.
I started the year wanting to work on some side projects I wanted to complete. Overhauling my .dotfiles, learning Elixir & Pheonix in more depth and some small FOSS apps were on the list. Sadly, I didn’t complete any of them in any detail as my time was dominated with my day to day roles. These are still relevant and I will carve some time out in early 2020 to pick these up so expect to see some posts on them. I did make a fulltime move to i3 and Manjaro as a daily driver and I couldn’t be happier. I should probably write more about that.
Leaving Open Energy Market was a big decision but the right one after 5 years. I do miss the awesome technical team I had there but I realise now that I was burntout. I had to walk away from the wider business. It has taken a few months but I am now fired up and thinking and working in a balanced and productive manner. Time and perspective have been great in helping me to see it was the right move.
Starting up my consultancy has been a massive step for me. I have been lucky enough to have had a steady stream of clients from the get-go. In 2020 I need to work on growing the brand and marketing our services. I also need to be harder with clients and ring-fence my time slightly better. I have a lot to learn in this space but it is so energising and inspiring to be working with such talented people in positive environments.
I was also lucky enough to get involved with Zinc this year as a fellow. Zinc is an organisation that aims to find solutions to the most important societal problems faced by the developed world. Their missions bring together researchers, specialists and founders which result in some unique companies that actually could address some of the more interesting and vital issues facing humanity. This is something I will write more about next year and is something I urge more people to get involved with. Again, meeting such passionate and energetic people, driven to really make the work a better place for everyone, has been inspiring on many levels.
On a personal level, the year has been mixed. We started the year learning how hard the impact of social media can be on teenagers. Supporting my son through a rough period was something I do not wish on any parent. It is not something I have written about but it has lead me to think hard about the value of social media and its impact on society. Once through that, we did get to finally travel to two places that we have always wanted to go. February saw us finally hit New York and be lucky enough to wander around Central Park in the snow. August saw us travel to Bali which was a stunning and beautiful experience.
So 2019 has been a mixed year but I feel I have come away from it a better person in a better position. I realise I am incredibly lucky to be able to say that and to have travelled and worked as I have this year. I am also incredibly lucky to be supported by my amazing wife and son. I am excited to head into 2020 and the new decade to see what they will bring. I hope everyone that reads this blog with any regularity has a great Holiday Season and that 2020 brings happiness to you all. I will be back on the 7th of January.
One of the projects I have been trying to do all year to overhaul my .dotfiles. I have a raft of customisations and settings that I have amassed over the years. Non more so than for Vim.
My .vimrc file is full of quick fixes and random solutions and settings. A lot I have forgotten about or are for plugins I no longer use or need. So as I am coding a lot more at the moment and living in the terminal I figured it was a great time to sort it out.
The first thing I have changed with my shiny new .vimrc is the plugin manager. I previously used Vundle and hook up plugins as git sub modules. A few years ago this was a great solution. But, managing git sub modules is more involved than it should be. After reading what the best option was right now for managing plugins I have opted for Vim-plug. This is a super simple plugin manager that removes the need for sub modules.
To install vim-plug you just need to download it and add it to your autoload directory. You can do this on Linux with the following command:
(Other OS’s are detailed on the projects Github page.)
You then need to add a section to your .vimrc file to define the plugins you want to manage. You define the plugins by adding a ling that starts with the word Plug followed by their Github repositories. An example will explain it better:
As you can see you can use either the full url or the shorthand url for the plugin repo. Vim-plug also allows you to defer the loading of plugins and has many different features. The project has a good tutorial and lots of examples.
Once you have added a plugin to your configuration you can install the plugin using:
And if you decide to remove the plugin after trying it then delete the entry for the plugin in your .vimrc and run:
To update the plugins you have configured then just run:
That is all there is to it. It is super simple and easy. It is also really fast as it uses parallel downloads where possible.
If you have any good plugins to recommend for Vim please contact me via twitter or email.
This week I completely managed to screw up some git settings for a project. I learnt that you can simply update the origin when using a service such as Gitlab/Github/Bitbucket. This can be useful as well if you are transferring code or repository ownership.
Firstly you need to see what remotes you have configured with:
This will output a list of the configured remotes such as;
There are two remotes configured based on where to fetch from and where to push to.
If you are not using ssh your output will almost certainly be based on https:
To update the remotes you first remove the existing entry:
So if the example we are using it would be:
You can then add the new remote details using:
In our example that might look like:
Hopefully this is a helpful but if you have question please contact me via twitter or email.
Not long ago I wrote about developer labelling. One of the ongoing things I have been thinking about is the cost of promoting junior developers. In the case of this article, I am referring to developers in their first or second programming role.
There is a cost with junior developers that you do not immediately appreciate. When you hire them you undertake to invest in training and in time.
Investing in training is an obvious win/win situation. You support the developer to learn and develop professionally. You also ensure that they have the skills and knowledge they need to be proficient for your company. You want good clean code developed to your expected standard. You also want your developer’s coding confidently. You don’t want them spending excessive hours on Google or Stack Overflow looking for solutions. As an unexpected bonus, I have discovered a positive side effect of training juniors. They share their newfound knowledge through conversation and at stand ups. This knowledge sharing can reaffirm other developers knowledge. It can also trigger conversations about improvements and standards within the team.
The total time invested is a cost that you may not appreciate at first. When a junior joins your team they will take time to get up and running. They will need support from the more senior team members. This means that those more senior team members are less productive. The junior developer’s own productivity will increase over time as their knowledge grows. Planning and estimating has to be adjusted for the junior’s capabilities. This all results in financial cost.
The benefits of hiring a junior developer on a lower salary can be offset both financially and in productivity.
So why when they ask for a pay rise, do we say no.
At some point, after the first couple of years, the junior developer becomes an established developer on your team. They know the product well. They have developed their skills and their productivity is high. They are clearly an experienced resource. They sit in a review and you give great feedback and then they ask for a pay rise. You have no room to pay the kind of increase they ask for or deserve. You haven’t budgeted for this. The company can not afford or does not agree with giving large pay rises. Three months later the developer has left for a company that will hire them at the salary they deserve. Demand is high for developers don’t forget, there are not enough of us.
On average at present, if you hire a junior developer, you will pay around £10k less a year than a mid-level developer. So when you have to replace your developer for a new junior you are going to incur costs such as:
Unless you work for a large company, you or one of your team will sacrifice time to go through a hiring round to fill the role.
A recruiter fee. If you are lucky enough to get 15% rates then this could be between £2.5k and £4.5k. (If you are not getting 15% rates at this level then you need to work on your recruiter relationships.)
You will invest in training.
You will invest your senior teams time in on-boarding the new junior and supporting their learning of your codebase.
You will lose productivity in the team as you return to having a less productive resource.
If you could and did sit down and calculate the monetary value of the points above I suspect you’d be surprised at the cost. As a leader, I would sit back and weigh up if this cycle is cost-effective against a £10k raise.
There is a flip side to this argument. As a junior developer at the start of my career, I could see the number of roles reduce if all teams did consider the arguments above. I would also argue that as a more junior developer, working for many types of company and across many projects is beneficial to your career. So it might be that even if your current role does offer you the money you deserve as you progress your career, you should still move on.
Like my previous article on developer labelling, this is really just a brain dump of thoughts. If you would like to discuss or have thoughts around this them please contact me via twitter or email.