Working from home sucks for a lot of people. Conversely, people are in no rush to return to long commutes to soulless city centres offices. A decentralised network of micro-hubs would allow people to work locally, inject accountability into communities and help regenerate the high-street. Micro-hubs are the future of office working.

What the hell is a micro-hub?

I propose the micro-hub as a small office (6–30 people), located in a suburban or commuter area, ideally on a local high-street. For larger corporations, a network of these hubs would be spread across large parts of the country. Micro-hubs are the corporate HQ reimagined; fractal, distributed, and local.

For some types of business (banking, retail), the infrastructure is already in place — micro-hubs could be incorporated into existing branches and stores, removing the need for a corporate HQ. For smaller companies, desk space at micro-hubs could be rented out, depending on need.

This is not a new idea

The 20th century saw a trend from localism to globalism. Beside the material benefits globalisation bought, it also exposed us to a new category of risk. Our drive towards centralisation and interconnectedness has led us to wider, systemic, cascade failures, of which Covid-19 is an example.

It’s easy to forget that centralised commerce was not the norm for most of human history, and is in fact a recent phenomenon. The modern, open plan office would appear as a form of collective madness to anyone born before 1900. Before this time, it was the norm that legal, insurance, advertising, journalism, and other white collar professions were smaller local offices. I see a shift from globalism back to localism, driven by advances in telecommunications, 3d printing, and other technologies.

Moving corporations from HQs to micro-hubs presents a large upside for both employees and organisations. Lifestyle changes for most people as they age. It’s not uncommon for younger people to seek a dynamic, big city lifestyle, whilst retreating into the suburbs, market towns, or further afield as they get older.

People are often held hostage to big cities longer than they would like due to work. A network of micro-hubs at a regional or national level would allow people the flexibility to change lifestyle, without having to worry about finding a new job. It would also boost employee retention.

From a recruitment perspective, employers would no longer be bound by geography. Micro-hubs would allow a much wider candidate pool, resulting in a more competitive and higher overall standard of candidate.

Customer service would improve also, but perhaps not in the way people think. There is often a disconnect between corporate, and employees who work on the ‘shop floor’. It creates a parallel universe for those in corporate, where eccentric jargon and woke-ism reign supreme. I see a future where I can walk into my local Greggs and order a vegan sausage roll knowing a slither of corporate management is working in the back office. An office environment where they have skin in the game with regards to the local community, and are exposed to receiving a good bollocking from irate customers, rather than powerless souls that are often used as customer service cannon-fodder.

Forget big corporations paying low taxes as a source of evil. They do far more damage in the way they destroy local communities. A localist approach is a fair and equitable approach. In a decentralised workplace, people can still get personal tasks done (e.g. dropping off kids at school). It can also help rejuvenate local high streets and bring familiar faces back into the community — a place to live AND work. A workplace that fosters a sense of community and accountability at a local level.

Learning lessons from Al-Qaeda

Large offices don’t scale. Here we can learn a lesson from Al-Qaeda. The terrorist group operates as a collection of cells, distributed geographically, with no distinct specialisation between them. This clandestine cell system has made it notoriously difficult to eliminate them — you cannot cut the head off of the proverbial snake. It is a great irony that the key preventing another 9/11 may be for organisations to mimic the structure of Al-Qeada.

Not only are decentralised office environments robust to terrorist attacks, they are also robust to power failures, water leaks, earthquakes, traffic jams, protests, riots, and a whole host of other ‘long tail’ effects that are catastrophic to corporate headquarters. From a business continuity point of view, micro-hubs make sense.

Final Thoughts

Maybe one day micro-hubs will all become a reality — it’s certainly something I would like companies to experiment with. We need to be brave to try it though, otherwise I fear a future of working from the dining table, or even worse, a lazy return to the failure of the open plan office.

1. The code you will find most jarring to review is your own, six months from now.

2. There are two types of code review, short blocks of code, which you will analyse and critique, and large blocks of code, to which you will give a cursory glance and say ‘looks good’.

3. Always refuse to review large chunks of code. Anything over 50 lines sees rapidly diminishing returns.

4. The more a developer is obsessed with displaying deep knowledge of a language, framework, or philosophy, the less likely he is to be a good developer.

5. The importance of testing is understated. The belief in testing is overzealous.

6. Prioritise testing the parts of the codebase that never fail, over the parts that fail frequently. That is where the tail risk hides.

7. Great code and great software are not the same thing.

8. Customers / stakeholders will always change their minds. Always. Always. Always. Accept this as a fundamental fact of life.

9. Don’t over optimise your code, unless your product is extremely mature, or solves a single, specific problem — and even then, don’t over optimise your code.

10. All developers need to learn the basics of UI and UX — even backend developers

11. You should always be thinking about the user.

12. Good UI design isn’t always about making things simple and shiny. Expert users may want complexity.

13. A steep learning curve is not necessarily a bad thing, if it allows an expert user to get things done quickly when learnt.

14. Instead of learning the latest library or language, most developers would be better served learning sales.

15. Think a good developer is expensive? They are an order of magnitude cheaper than a bad one.

16. It amazes me how many software developers I see take a shitty or superior attitude with stakeholders in other parts of an organisation. If you are a developer, you are in the customer service business first and foremost.

17. To a user, time has an elasticity. The first few seconds of a loading screen go by quickly, the new few seconds take an eternity.

18. No new page or view should take longer than five seconds to load.

19. Have a conversation with a fellow developer in which you both pause for five seconds each time you give a response. You will discover a new appreciation for the frustration of loading times.

20. Coding tests during interviews are pointless. Far better to give candidates a stakeholder test. Offer competing and conflicting requirements for a piece of software and watch closely how they respond.

21. People who say ‘just read the documentation’, haven’t read the documentation.

22. The number of bugs a user encounters vs. how irritated they become, is not linear. The first couple of bugs will be met with mild annoyance, the third and fourth with utter contempt.

23. Good developers never complain to the end client. Great developers never complain.

24. If a requirement is intractable, or impossible to deliver, always have an alternative suggestion lined up before communicating it to the client.

25. Any challenges you encounter are more convincing to the client when you DON’T use technical language to explain them.

26. Wait until a language, library or framework has been around for at least five years before learning it. If you have to use it before then, just learn enough to get by.

27. The vast majority of a software developer’s career is learning just enough to get the job done. The myth of the all-knowing developer is just that, a myth.

28. Depending on what type of person you are, time constraints will either kill creativity or enhance it.

29. Every developer thinks the code they inherit is shitty code. The developer who comes after you will think your code is shitty too.

30. Software development is one of the most cult-ish industries around. Avoid fads in methodology, language, or design like the plague.

31. Every organisation has their own definition of ‘agile’. None of them are correct.

32. Over time, technical jargon seems to morph into management jargon. Be careful not to conflate the two.

33. 99% of software projects do not need a CI pipeline.

34. Don’t waste time trying to create the perfect deployment process, it is a form of technical masturbation.

35. Your users don’t care what programming language you use.

36. It is more important to understand different programming paradigms, than a large number of languages.

37. Keep your functions and class methods short. Under 50 lines, and in most cases far less.

38. Requirements gathering should be like sculpting a statue. Start with a rough outline, and use iteration and feedback to refine and polish.

39. Don’t be afraid to recycle code.

40. Do not bother to deliberately memorise large amounts of syntax that is easily available as an online resource. Save that capacity for more abstract concepts.

41. During requirements gathering, what is not said can be more important than what is said. Politics, Organisation culture, and other intangibles matter. Account for them when creating your product.

42. The more developers that are assigned to a delayed project, the longer that project will take to deliver.

43. Functionality and aesthetics are more closely related than may think.

44. 95% of SaaS businesses can be replaced with a spreadsheet.

45. If you only have enough time to make the design great or the architecture great, choose the former. Users are much more forgiving when they love the look and feel of a product.

46. Under promise and over-deliver.

47. Decentralise your architecture as much as possible, even at the expense of efficiency

48. The only start-up you should be working for is your own.

49. The meaning of the word start-up has become so diluted as to become meaningless. If you’re not worried if you’re going to go bankrupt next month, you’re not working for a start-up.

50. If you’re a developer, It is better to work for managers who are non-technical. Technical managers will concentrate on what they know best (technology), vs. outcomes. This lends itself to endless (pointless) debates over the tech stack and architecture.

51. An average developer who is a great communicator will be far more successful than a great developer who is an average communicator.

52. The last ten years have been about big data, AI, processing power, and storage. The next ten years will be about perfecting human computer interaction to enable users to generate insight from it.

53. It takes far more effort to write simple code, than it does to write complex code.

54. Context switching is cancer to productivity.

55. Have the courage to keep your daily stand-up comments brief. Resist the urge to ‘pad out’ what you are doing.

56. Most of the team aren’t listening to your daily stand-up, they’re thinking about what they are going to say, or have already said.

57. Most of your career will be spent developing CRUD apps, in one form or another.

58. If you’re writing a feature that has to interact with another system within your organisation, increase your time estimate by a factor of four. If you work in the financial sector, increase it by a factor of eight.

59. For every database table you create, add ‘created’ and ‘updated’ timestamp fields. This will future proof the queries you make.

60. Reduce database tables to the smallest atomic unit possible. If you’re re-using a selector frequently, create a new table for it and use a foreignkey.

61. It is better to store irrelevant data in a table, than it is to prune data you don’t think is relevant, only to add it later. Data storage is cheap. Development time is not.

62. 100% of projects need version control. Develop the discipline to use it well.

63. You are a truly great developer when you remove more lines of code than you write.

64. Software is easy. People are hard.

65. Never disable Copy / Paste in your app.

66. Debugging code is twice as hard as writing it. Therefore, don’t try to make your code too clever.

67. UX is the art of misdirection. And a beautiful UX will misdirect beautifully.

68. Not every developer is a designer, but every developer should treat the user as their compass.