Simon McManus

You can find me over on bluesky: bsky.app/profile/simonm…

@philhawksworth It's similar, but makes it much easier to keep the html in html files and just compose it all with js.

@philhawksworth codesandbox.io/p/devbox/sizla…

@philhawksworth That's the sort of thing I built sizlate for: npmjs.com/package/sizlate Will try to post an example later on.

@psd Love this Paul. No doubt you will be great in the new role. Hope you are well.

Wrote a piece about our experience with Hypothesis Driven Development at Trainline: medium.com/trainline/less…

@jackmcconnell developers.google.com/search/blog/20…

Went to a ploughing competition. Entered into the straight furrow competition. My entry was described as wonky! (It was)😂😞

moved the blog over to @eleven_ty and made a little wrapper to support layouts using Sizlate: simonmcmanus.com/posts/eleventy…

@LucaColonnello Always be refactoring. 👌

To be clear, there is no way you can know all the requirements upfront, so I’m basically saying, stop moaning about refactoring getting out of scope, and just do it. The right way is to talk about it with your POs and Team Leads and factor the cost as a prerequisite / blocker.

KISS+YAGNI mean refactoring when time is due and new requirements make the current solution obsolete. YOU CANNOT just add on top of what you have, cause when you built it, the current requirements were not there. Accept the refactoring cost or don’t use those principles at all!

Magnolia tree is looking 👌

This looks interesting. A slightly different approach to sizlate but I suspect it will work nicely. Nice to see more libs using standard html with css syntax for templating.

The full post is available at simonmcmanus.com/posts/engineer…, what are your engineering principles? Did I miss any?

Over the last year, I've been referring to my engineering principles quite regularly. I thought it would be worth writing them down my top 10:

Continuous improvement As engineers, we never stop learning, which means there is always room for improvement. Actively seek it out and challenging assumptions around the status quo. It's vital that engineers feel empowered to bring about change. #continuousimprovement" target="_blank" rel="nofollow noopener">simonmcmanus.com/posts/engineer…

Integrate continuously To operate at scale, it's often necessary to separate concerns and have clear boundaries so people work independently. The risk is the pieces built-in isolation won't work in unison... #integratecontinuously" target="_blank" rel="nofollow noopener">simonmcmanus.com/posts/engineer…

Last responsible moment On big projects, it's often tempting to do some work up front to figure out the best solution. In reality, it's better done as close to the actual work to ensure the solutions are relevant. #lastresponsiblemoment" target="_blank" rel="nofollow noopener">simonmcmanus.com/posts/engineer…

Embrace the unknown By Acknowledging what we don't know, we remove assumptions from the process. We can then dedicate time to understanding and solving those problems in isolation. #embracetheunknown" target="_blank" rel="nofollow noopener">simonmcmanus.com/posts/engineer…

Remove assumptions The best way to remove assumptions is to break a task down into smaller delivery units and make sure you have clear acceptance criteria for them. Keep breaking it down till there are no assumptions of concern. #removeassumptions" target="_blank" rel="nofollow noopener">simonmcmanus.com/posts/engineer…

Justify complexity t's not always possible to avoid complexity entirely. We can minimise it by insisting any complexity introduced has to demonstrate it will add more user/business value, keeping unnecessary tech/requirements away from your code.  #justifycomplexity" target="_blank" rel="nofollow noopener">simonmcmanus.com/posts/engineer…

Tight Feedback Loops Work closely with designers, optimise for tight feedback loops and short iteration cycles. The sooner you can get real users testing your solutions, the better. #tightfeedbackloops" target="_blank" rel="nofollow noopener">simonmcmanus.com/posts/engineer…