Have you ever walked into a supermarket, pharmacy, or department store looking to buy a specific item, only to find the layout confusing? Perhaps you ended up aimlessly strolling around, purchasing other items? This is deliberate, and known as the Gruen Transfer.

The 'Transfer' part is the moment that you, as a consumer surrounded by a deliberately confusing layout, lose track of your original intentions.

We've all experienced it, and now it's starting to consume the internet. It first appeared on Facebook, with the introduction of the feed. Originally intended as a way to simplify updates from your friends, and hold your attention captive for longer. However somewhere along the line, the feed became more than that. Facebook now feels more confusing than my local department store, and my original reason for visiting (keeping up to date with friends & family) is quickly forgotten. The last time I checked Facebook, maybe 10% of my feed was updates from friends. The rest was a combination of ads, memes, and influencer marketing videos, leaving me doom scrolling endlessly.

This isn't relegated to Facebook though, or even social media. So many websites are now designed to disorient you upon visiting, so that you start acting impulsively. This can even happen in a relatively benign way - who hasn't looked up something on Wikipedia and fell down a rabbit hole that ended looking at a list of animals awarded human credentials?

It pops up in other areas as well, closely associated with several UX dark patterns. If you've tried to permanently delete your account from any major social network, you’ll know what I mean. It is utterly confusing to find and navigate to the page you need, and the site will desperately conjole you into doing something other than deleting your account. It's the same for trying to alter your insurance policy, cancel subscriptions, spend frequent flyer miles, and so on...

I wonder where all this will end? There must be a point at which the friction generated by needless complexity has a detrimental effect. A kind of Laffer Curve of web design.

In the EU, it is a legal requirement to allow your customers the same method, with the same number of steps and complexity, for canceling as for subscribing. So if it takes 10 seconds to fill in a form online to get subscribed, they need to offer the same ease of use for canceling.

I like this idea of ‘complexity’ as a measure for legislation. Now if only they could apply the same thing to my local Boots when I'm trying to buy toothpaste.

from dateutil.easter import easter  
print(easter(2010))  
2010-04-04  

The function also has an argument, where you can specify the type of Easter calculation you would like:

1 = Easter Julian
2 = Easter Orthodox
3 = Easter Western

print(easter(2010, 1))
2010-03-22  
print(easter(2010, 2))
2010-04-04  
print(easter(2010, 3))  
2010-04-04    

You're welcome. Happy Easter. 🐰🐰🐰

Bend tech to my will,
They think I’m a genius.
I just Google stuff.

Two minds intertwine,
Code flows as one hand guides hands,
Ideas take flight.

Tests run while we sleep,
Errors caught before they grow,
Code safe, calm, and strong.

Plans change every week,
Sprints end with no code to ship,
"Agile" sounds so false.

We gather to talk,
Blame circles, coffee runs dry,
Next sprint more of the same.

Lines twist, bugs hide deep,
Cursor blinks, patience runs thin,
"Why do I do this?"

Daily standups drone,
No blockers, no goals are set,
Just coffee and talk.

Loops twist, branches merge,
Unraveling feels futile,
Lost in tangled strings.

Forgot to branch off,
Now the fucker doesn’t work.
Wish I could revert

A missing comma,
That took me two days to find.
I hate this language.

Navigating the world of contracting has always been a balancing act, but for IT contractors in the UK, IR35 has introduced a whole new level of complexity. Designed to curb tax avoidance of individuals working as self-employed contractors while effectively operating as employees, the IR35 legislation, introduced in 2000 (but only given teeth in 2019) has left IT contractors in something on a limbo state.

I believe the legislation is a product of a bureaucracy in its purest form. We now have a situation where contractors working 'inside IR35' pay the same tax and national insurance contributions as regular employees, but have absolutely zero rights. No notice period, no sick pay, no holiday pay. Nothing.

However, this article is not to a debate of the legislation (there are already scores of articles online and there is nothing new to cover). What I'd like suggest is a new structure for IT contractors to work - one that has been used by accountants and solicitors for decades - the LLP.

I feel there is a real opportunity, in the wake of the new legislation, for IT contractors to change their relationship with clients - who for the most part view them a 'bums on seats' for a project. IT contractors banding together in LLCs to create bespoke IT firms gives them the potential to be truly self employed. The LLP (as opposed to the standard LTD company structure) is a hybrid between a traditional partnership and a limited company. It gives individual members legal protection, as it is still a separate legal entity from its partners, and offers them limited liability.

LLPs also comfortably resolve the IR35 tax issue, as LLPs benefit from "pass-through" taxation, meaning that profits are not taxed at the LLP level but are distributed to members annually, who then pay income tax on their share of the profits. LLPs also offer the benefit of less stringent reporting requirements than LTD companies, which reduces the administrative burden.

But the real genius of the LLP structure lies in its partnership system. The partnership is managed by the members, who typically have equal rights unless otherwise agreed upon in an LLP agreement. This means there is no 'equity' as such - if a partner leaves (or is voted out), they surrender their equity. As IT contractors are essentially a 'pay for time and skills' industry, this resolves the tricky situation where one contractor may leave, or not be pulling their weight, yet still own equity in the firm.

I really think there's huge potential here.. I would love small IT partnerships to become as common as accountants, solicitors, or architects - a structure in which reputation is built on the work and name brand of their partners, is flexible enough for partners to come and go, is tax compliant, and where IT contractors truly have the scope to be fully independent.

One of the challenges working as a software developer is that friends and family tend to view 'tech' as an amorphous blob. Since I work 'with computers' I become the go-to person for anything remotely technical - including building websites, providing tech support, fixing hardware (the assumption being that I also know how to fix televisions and other consumer products). I even once had a friend ask me for help with his electric toothbrush. This has led to frustration and feeling like I'm trapped providing free labour. 95% of the time, all I am doing is Googling the problem, and following advice on a blog or YouTube video. People can do this - they just don't want to.

If you're like me, and find it hard to say no to people, these 'quick favours' quickly turn into nightmares. Evenings and weekends fill up, and people expect more and more from you. After many years of saying yes, I've learnt that the only solution is to get comfortable saying no. Friends and family don't like it in the short term, but it saves arguments or worse down the road.

I've often wondered why people don't expect free labour from other trades. My family doesn't expect my decorator uncle to come and paint their house for free, my friends don't expect our accountant friend to file their taxes pro bono, so why am I expected to provide my skills for free? I think a lot of it has to do with a poor understanding of tech roles - people underestimate just how much work goes into building a website, creating an MVP, or producing graphic design. Maybe this is Hollywood's fault? after all they tend to present coding as the rapid hammering of keys and a flurry of green characters across a screen to the sound of techno music. If only the reality was as exciting (and quick).

Over the years, I've noticed there seems to be an invisible hierarchy to 'quick favours': -> Family will expect free tech support -> Friends will expect free web / graphic design for their lifestyle business -> Colleagues will expect a free MVP built for their 'amazing idea'.

Unfortunately, these types of favour rarely have an end date - once I make the commitment, it's open ended and ongoing. If I provide tech support, I become the go to tech support person forever. The absolute worst are those who tell me 'what I did last time must have caused the new problem'. For websites, I will be constantly amending them, maintaining them, sorting out hosting... and of course if the site ever goes down, it's my fault, and I will get an urgent call from you. For MVPs, I will get trapped in an endless cycle of adding 'just one more feature', as the reality slowly dawns that their amazing idea may not be so amazing after all.

Over the years the years I developed coping strategies that avoided me having to say no directly. Here's a few of them:

• Doing such a bad job of it that family members think I'm incompetent and don't ask again.
• Responding quickly with 'sure, as a favour I'll give you 25% off my normal fee'.
• Politely trying to explain the differences between software development and TV repair.
• Hiding / not responding to requests.

... all of these tactics have been met with limited success, and often result in more stress than just doing the favour in the first place. The only thing I've found that works, is a simple no, the less explanation given, the better.

• Sorry no, I don't know how to do that.
• Sorry no, that will take too much time.
• Sorry no, I will have to charge you for that.

I will not do you a quick favour.

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.