Fraser Chapman

I just watched Daniel Terhorst-North's talk at Kotlin conf, having sadly missed it in person (nothing to do with being hungover on day two of the conference). Daniel is the originator of Behaviour-Driven Development and gave a talk titled 'The best programmer I know'. A few interesting takeaways: - You don't need a degree to be an exceptional programmer - Everyone is a kinesthetic learner. Some people might lean towards seeing or hearing things, but everyone learns through doing, so just start and iterate as you go. Lean into uncertainty. - Invest in the product - not the code - Watch your users and find out what frustrates them - TDD pays off. Daniel's team at BP won a software quality award for their trading system. Unlike other teams, they found zero bugs during six weeks of UAT, thanks to TDD. BP paid them to stay on for the UAT period, which they spent in the pub. If that's not an incentive to learn TDD, what is?" - Explore different languages, tools and paradigms to give you more options and help you solve specific problems throughout your career - Help others - teaching is the best way to learn - Overall takeaway for me is that soft skills are clearly equally as important as hard skills in software engineering Worth a watch. https://lnkd.in/e8bau4X9

15

1 Comment

🚀 Feeling the pain of TDD slowing things down? Wondering if it truly has practical value?  In this post I shared a few insights based on my experience on how it can enhance code confidence and efficiency.  As always keen to hear how other teams implement TDD in complex products. Check it out! 🛠️

12

I've started a long-deferred read through of Team Topologies, which speaks to some of the problems I was talking about recently around the ways "utopian" software development maxims can fail when they encounter the "topos" of an organisation's incentive and communicational structure. There's a thought-provoking section on John Sweller's 1988 breakdown of "cognitive load" into three categories ("intrinsic", "extraneous", "germane"). The thought it provoked in me was that I tend to disregard the burden of the "intrinsic" when looking for ways to reduce "extraneous" load (ways a codebase and development environment distracts me with boilerplate and arbitrary irregularity) and gain traction over "germane" problems (those particular to the domain we're working in). For me, leveraging advanced language features to eliminate boilerplate and build out a little embedded DSL that can express the problems I care about is an obvious win - I often refer to Paul Graham's maxim that you should first create the language you want to solve your problem in, then solve your problem in it. The problem with this is that it can shift extraneous load into intrinsic load, by requiring programmers who were comfortable with repetitive constructs using basic language features to familiarise themselves with much more advanced features (and the DSL's idiomatic usage of them) for the sake of eliminating what may seem to them to be quite harmless repetition. This suits me personally, because I like having an advanced model of a programming language in my head and using it creatively, but one isn't accounting properly for the distribution of cognitive load if one doesn't also take "intrinsic" load into account. I think of Golang as an intentionally low-intrinsic-load language - it has a small kernel of features, and is structured in a way that discourages higher-order abstraction over those features. If in doubt, write another for-loop! By comparison, I remember Scala adoption at TIM Group being an intensely painful experience for some of my colleagues, because it introduced so many constructs and type-level features that could be used in so many colourful ways. While I was elated by its endless opportunities for minimising extraneous load, they felt the burden of ballooning intrinsic load, and the frustration of being temporarily deskilled by the change of fundamental environment. The real art is to leverage small changes of technique and perspective, that will fit comfortably in everybody's head, to chisel away at extraneous load, until they feel that the nuts-and-bolts of their tasks are simpler than they have ever been.

12

We have TDD and BDD and DDD … I’d like to respectfully suggest another acronym CDD - CI Driven Development. Unfortunately this isn’t IMHO a good thing. I’ve worked in several places now where CICD has taken over and there are extremely complex pipelines and corruptions of code to ensure that there is comprehensive a complete coverage of every possible scanning, testing, analysis, and checking … but in the pipeline ONLY. What those that push CDD forget is that developers need to run/reproduce these checks locally! I recall a video of a talk given by Daniel Terhorst-North some time ago where he suggests running builds manually to check that you still understand what is going on. I think this excellent advice has been completely ignored and swamped by vastly complex GitHub actions or GitlabCI script, mountains of Groovy code, huge docker compose files. I would submit that your CI should simply call Make targets (or similar commands for the relevant build tool). CI scripts should be simple. Aim for build scripts that help a developer run things locally really quickly - make test should whizz through unit tests for example. Also can we PLEASE stop assuming everything is x86: we live in a world with at least two major architectures and a third on the rise: multiarch builds should be the norm!

80

56 Comments

"If you haven't been able to maintain and improve the quality of the current codebase, how can I trust that a rewrite won't lead to the same issues?". This single rejection changed the way I approached software improvement forever. Whilst I was passionate that a refactoring needed to happen and I strongly believed that my proposed structure would be superior to the existing one, I could not refute my manager's point. The code didn't become unmaintainable because it had lacked an elegant design in the first place. It had become unmaintainable because we'd failed to implement and evolve it whilst maintaining quality. The problem we needed to solve was not designing elegant solutions up front and implementing them. And then waiting for the code to degrade over time until we had no option but to go back to the drawing board and rewrite the whole thing from scratch. The problem we had to solve was how to manage change whilst maintaining quality indefinitely. By creating the constraint that we would not be allowed time for large refactorings and rewrites, my manager forced our team to think of better strategies to evolve the code and improve quality a little every day. He effectively introduced me to the concept of Continuous Improvement.

179

28 Comments

I’m super excited to dig into this book, #FlowEngineering! It arrived today! “ as scale increases, waist and delay grow exponentially, and interdependence exacts a massive tax on the business” “We need to dismantle and decouple crippling dependencies and enable effective descaling to improve flow.” Here’s to improving flow!

31

10 Comments

Your dev team is under resourced Spoiler - it always will be Don't get trapped thinking if you just had two more (or fifty more) devs you'd be able to work through the backlog and get ahead. The problem is that teams try and filter and prioritise *down stream* on outputs. 100's of outputs. Try filtering and prioritising *up stream* on strategic outcomes that matter to the business (and across the business).

12

9 Comments

If you’re curious about TDD and want to know more, I highly recommend giving this talk by Kent Beck from at today’s techexcellence.io conference a watch: Personally, I find TDD great for enhancing my focus, clarity and speed when writing code. It really takes the stress out of it and it’s just a buzz to watch your failing tests go green after you’ve implemented your code. https://lnkd.in/ga6D53DJ

7

2 Comments

Day 2 at #LeadDevLondon LeadDev What a great conference! I'm exhausted. More fantastic talks today and I got to meet loads more exciting people (hi to you all!). Again too many talks to comment on individually, so again I'm going to pick out themes. 1. How do you make decisions? This seems to have been a running theme across all three days, but there were great talks about it on day 2. The first thing is you are going to need to notice that you are making a decision at all and take a moment to step back. Things to weight up: - Do you have existing biases? - Have you stepped back far enough to consider all the options? Throwing in some wild options is a good way to open it up. - What are the upsides? - What are the risks? - Who needs to buy into the decision? (Not just your line, but also other teams who's support you are going to need, or customers/teams that you want to use the output). - Do you have the skills? Or are they skills that your team would like to gain? - What are the maintenance costs? If this is a migration are you really going to be able to get rid of the legacy system? How quickly? - What are the repercussions for other teams/areas? - How are you going to get feedback as the project progresses? Metrics? People? - Above all, is this going to be fun? As you go through all those questions and indeed the project be curious, humble and empathetic. 2. Humans > machines, metrics, process.......... If you are putting people first you probably aren't going to go too far wrong. That isn't to say there isn't a place for all those other things, but they are there to assist people, not the other way around. If people are giving you a clear signal, you better listen to it. 3. Finally some practical advice from the bug all stars talk: - Be explicit in your APIs, make it super clear exactly what parameters/outputs are. - Get help whatever help you can to validate your code, whether that is from people, or from tools. - Don't try to solve difficult problems that have already been solved, use existing hardened libraries. Thanks to all the speakers/organisers, you were amazing. Thanks as well to my LeadDev buddies: Jen Kitson, Yanqing Cheng, Alice Twist, Daniel Phillips and Macauley Davy, sorry I didn't catch you all for the photo before you left. Finger's crossed I'll be back next year!

63

2 Comments

A management conundrum. Last night I met up with an old colleague and the conversation turned to code written by super intelligent developers. Code which is extremely clever, but at the same time very difficult to understand and manage. Code that the average developer cannot maintain, and which even senior developers will take an inordinate amount of time to understand. My role as engineering manager is, amongst other things, to ensure the viability and maintainability of any software that is released into production. I am of the school of thought that software should be written as simply as possible, and that clever code is in fact not clever at all. I would like to discuss techniques on how one might manage said super coder, encouraging them to reduce the complexity of their code. The obvious initial steps are to discuss with the coder the impact of their clever code and attempt to get their buy in for the maintainability of the code, but where do you go if this coder considers simpler code as inefficient, boring, beneath them or any other reason? I would further float the potentially controversial opinion that the company might be better off letting the individual go if their codebase remains unmaintainable by 90% of developers.

9

5 Comments

What do train crashes and software engineering have in common? Lots, as it turns out! A great starting point is how we reflect on the systems and processes around us and importantly, the value of a blameless retrospective. One of the most common questions I get asked is "Did the driver get sacked?". A more important question is "what systems were modified so another driver couldn't accidentally influence the same outcome?". How is your team reflecting on their work and collaboration? Are your colleagues and teammates happy contributing improvements or is everyone quiet avoiding the finger of blame?

77

9 Comments

I've seen a few posts today around the subject of advice for junior developers. I have a few years experience now so I thought I'd give my own: * The most senior developers are comfortable asking the stupidest questions. Ask away. * Give feedback on your progress early. When you are halfway through the estimated duration of a ticket, think if you are halfway done with the work. If not, tell the team lead. * The moment you think you may have made a mistake on prod, pull in a senior developer then. What worries me with juniors isn't that they might make mistakes (we all do), it is that they delay in reporting it. Be more trustworthy than your peers. * Find a process for turning off work mentally after work. For me, running works but YMMV. * Practice planning all of your work. That means guessing and WRITING down steps in some form before you start, just for yourself. This gives you estimation and planning super powers over time. * Boring technology is almost always the best. You might have to fail using some new fangled stuff to learn this. * Learn the art of q contained side project. Look up Readme Driven Development for guidance. Anything I missed?

30

1 Comment

I published a guest blog post on the Resourcely blog about the growing complexities and increased expectations of software developers. Perhaps we can learn something from the automotive industry: https://lnkd.in/e85prQY3

79

1 Comment

Now that the Microsoft AFO UK redundancy consultancy period has concluded, I can start to share details of where people are headed. Firstly there are people not actively job hunting for a software engineering role. - A decent number of people are taking the opportunity to go travelling for an extended period - A few folk are looking at changing career - e.g. starting a masters course, going into teaching, etc. - A bigger chunk have decided to take a couple of months off and begin job hunting in September. They'll have an easier time then, because they will have a stronger network.  - And finally let’s not forget the few that are still processing the shock; spare a thought for them. For the majority who are actively job-seeking though, early results are in. I'm thinking of it as like election night, there is excitement around those initial results, and we can start to form narratives, but they won't necessarily reflect the final picture. The job market dynamics will likely shift after the summer, interview process lengths vary by company size, and my guess is that those taking a relaxed approach may find themselves in different roles compared to the early movers. Nevertheless, here's the landscape so far: - Startups, with available funding, have moved the quickest  - Medium-sized companies are beginning to make offers. - Larger companies, with longer cycles, are interviewing, but not yet complete. Except Nvidia, who have hired a big bunch. Here are some specific destinations I've heard about within Engineering, with a very strong bias towards those "close" to me.  evroc (2) Oakdoor UNDO Squarepoint Capital Hymans Robertson Ciena Kraken NVIDIA (10+) Technical consultancy Microsoft (2) Update 5th Aug: NVIDIA (5 more, making 15 so far) Deliveroo (2) Cisco (1) Checkout.com (2) Cellular Origins (1) ---- Outside Engineering, I'm less in touch with where people are at, but I've noticed posts of people moving towards existing customers:  Award Consulting (2) weavix https://lnkd.in/egnSKVYd If you have more updates to add, please share in the comments!

171

12 Comments

TDD is expensive Like many other niche technologies Delivery of software is not only a technical problem It’s logistical and people problem as well It can be using Kotlin in Java company It can be adding a better database engine It can be applying Event sourcing to all systems You can say all of those are great But there are a couple of non-technical problems 🧠 Knowledge The whole team must know the new solution They need space to learn and practice You may get training from an expert Both cost money and time 🚦 Risk You face the bus factor What if the devs will leave? (they will) How will you maintain the niche solution? How much will it cost to hire or train a replacement? 👩 Hiring Adding new technologies narrows the pool of hires The more niche you go the harder is to find a good fit The longer hiring process will strain delivery You'll have to balance with higher salaries ☯️ Alignment What about your current team? 80% of them like tests but aren’t fans of TDD What will you do? Force them to learn or let them go? The culture will take a hit and retention will sink What can you do instead? Keep it simple Keep it boring Focus on the basics Drive incremental improvement Find alignment before picking new tech Get excited about the features and business If you don’t need to fix niche problems You get more time to deliver value

24

13 Comments

#opentowork Unlike 'some' UK politicians from both sides of the house, I’m not here for the freebies… Instead of accepting a free holiday in the US or tickets to the latest must see show or game, I’d much rather be paid to do what I do best—creating awesome, custom development solutions that make life easier for businesses and organisations. Why settle for dodgy handouts to get something done when you could have a Product Engineer / Full Stack Developer with years of real-world experience, cutting-edge skills, and a refusal to get distracted by all those shiny political "gifts"? 🚫🍷🍾 🏖 ⚽ If you want results and not a scandal, drop me a message. I promise you’ll only have to bribe me with work, and I’ll deliver the dev magic. Then let us toast our success. #NotAFreeloader #WorkNotPerks #DevLife #HireMeForRealResults #opentowork #php #javascript #remix

9

4 Comments