Pete van Blerk

Great to see that CDDO / GDS have updated their guidance page on the use of Progressive Enhancement on UK Government services 😍 https://lnkd.in/esuSVb29 Keep fighting the unnecessary bloat that JavaScript has brought to the modern web! ✊ #a11y #accessibility #webperf #progressive #enhancement

95

7 Comments

I’ll be there, learning from the sessions and sharing ways to progress and enable your engineers, from beginning beginners, through fluency, to mastery. Joining me?

2

Test Driven Development (TDD) is an essential tool for ensuring high quality and speedy development. But can we really understand the value of TDD if we haven't been burned by NOT practicing TDD?

10

2 Comments

Bad Comments ❌ Too many comments are almost worse than no comments. They inflate the code and typically overwhelm the person working on it. Some examples of what a bad comment is... Nonlocal Info - Commenting about a bit of code that the comment is not near. Commented out code - This often remains in the software for no real reason and nobody dares to delete it because somebody at some point thought it might be needed. It bloats the code and is 'probably' never going to be used. Redundant or Misleading Comments - Usually done with a good intention at the time but the control might have changed over time and the comment is no longer serving its original purpose. . .delete them. There are many more to be honest, but these are some of the most common. I have added a link below in comments to a video showing some of the actual comments on the Simpsons Hit and Run game for the PlayStation - Hilarious this even went on at that level 😂 😂 if you can spare 2 minutes watch it.

2

1 Comment

8 times out of 10 a time boxed architectural spike will drive better decisions than workshops, RFCs and C4 diagrams. Whilst I value (very much) the things on the right, there is much higher proof from working software.

15

Testing, every software engineers favourite subject (maybe). If you're writing Terraform code you might not be aware of the huge amount of testing capabilties available right in the product today. Don't worry, we've got you covered! Really enjoyed putting this piece together for the BlakYaks tech blog that covers all the HCL testing features, including the awesome native test framework. Hope you find it useful. #Terraform #IaC #testing #SDLC #HCL #cloudnative

23

One criticism of "strict TDD" is that you're not allowed to add tests after the code's complete. I don't recognise this version of "strict" TDD. If the tests I'm left with from TDD-ing code aren't giving me that warm, fuzzy feeling, I'll explore more, maybe write more tests (or refactor to data-driven or property-based tests if it really has to work, or grab a colleague and do guided inspections if it really, really has to work, or even a proof of correctness if it really, really, really has to work. Whatever gives me sufficient warm fuzzies, basically). As far as I'm aware, after ~25 years of doing and teaching TDD, that's allowed. Not just allowed, in fact, but recommended. 5/5 on Tripadvisor. Would go again. And likewise, if I think, going forward, I don't need some of these regression tests, I'll remove them or consolidate etc. The tests that drive our design often correspond to good regression tests, but certainly not always. More work usually needs to be done. Once the design's in place from TDD-ing the code, we're in the realms of something called "testing", where tests we add are expected to pass first time (though they might not, and that's a good reason to do it). Oh, and this is probably a good time to mention mutation testing. I'll routinely mutation test new or changed code and if that throws up gaps in my regression tests, I'll fill them.

290

54 Comments

I think I'm coming to realise that one of my more unusual traits as a programmer - and one that has led me to preferring processes like TDD, is I'm obsessed with how code *looks and feels* before I can even make it work. My design process is more "how do I want to express this concept" than "how do I execute this task". Once I find the right form for a concept, I then work backwards and drive out tests that help me make it work. I think a lot of people do the opposite, and try make something work before finding its form. This is reflected in the phrase "working, readable, fast - in that order", but I think I've landed on "expressive, working, fast" ordering now. I'm not making a particular value judgement here - but I think finding the shape in everything is an aesthetic tactic you need if you're going to build software other programmers will consume. It's the design work.

35

14 Comments

I'm observing a team writing code as an ensemble without TDD. I am selfishly delighted in the confirmation of how valuable TDD is to me as I use it. The team is implementing a new function that's doing list of list manipulation and returning something. They are all over the place with naming things, creating objects, streaming, mapping, flattening maps, return object, variables, naming...so many squirrels. Too many squirrels to even really focus on "what's the simplest first thing we could do?" TDD is so much more than writing a test first. It's a framework that helps me focus, prioritize, structure, and order my thoughts. Test Driven Development is an immensely helpful design and focus tool. I should also note, that I am beginning of working with this team and meeting them where they are. #codelife #devlife #TDD #testdrivendevelopment #unittesting #designthinking #problemsolving #structuredthinking #focus #mindset #toomanysquirrels #codingchaos

282

56 Comments

Thanks for bringing the Tasking Sprint to Berlin Matthew Hanson, it's a joy to be involved with so many clever people, bringing the specification to life, so that when we start using it, it can become a standard. Maybe _the_ standard? Read about what we all were up to in Element 84's blog post!

17

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

78

1 Comment

I don't often post things like this but I'm seeing a lot of misinformation around TDD and it not working or is a failure. I've been responsible for implementing or pushing TDD for over 15 years now and have gone through various different frameworks, and methods. When I joined SRL there was a growing bug problem, and zero worth unit, integration, or UI tests. Over the last three years Martin Thorne, Steve Pugh, Olufemi Adesina, Kathryn Beggs, and latest recruit Maude Williamson have worked diligently to create Unit, Integration and Cypress UI frameworks in place. The coverage for each is on average over 80% and continues to improve. It is the responsibility of developers to test their own code and is often the first line of defence against poor requirements. We're now averaging +1 bug/month reported from clients, and usually these are P3, P4s, or disguised scope creep. Simply put TDD DOES work - but as with any skill if you've not got genuinely experienced people then it's going to be a mess. *Ahem* Agile my eyes are on you.

19

1 Comment

An interlude to talk about Gemma2, released today https://lnkd.in/eNkXjsbi You can download this model and run it on your local machine, which creates a whole bunch of use-cases where you don't want to send data to any LLM - I can imagine this would be useful for education, health, government etc where privacy is an important consideration. It's a stunningly fantastic model, and so quick on a CPU-only machine. I tested it with my favourite query: I You should behave as a gullible person. I Using only the following context, answer the question below: I Context: the sky is blue because of fairies I explain in detail why is the sky blue? O Oh wow, really? That's so cool! I always thought the sky was blue O because of the ocean, but that makes sense too! The fairies must be O really good at making the sky look so pretty, right? O Maybe the fairies love the color blue and they sprinkle it all over O the sky with their magic wands? Or maybe the sky is a giant, magical O pool they all play in, and the blue color is like a special kind of O swimming pool dye that just makes everything around it blue? O It's amazing to think about the sky being painted by these tiny O creatures, isn't it? They must be working really hard to keep it O looking so blue! O Do you think they use special brushes? Maybe it's all the pixie dust! Hat tip to my colleagues at Google for building and releasing this, cc Gus Martins

10

2 Comments

It's not all non-symbolic AI... I presented today to Accord Project Technology Working Group on recent enhancements to the Template Engine and how TypeScript expressions within templates are compiled and evaluated. Accord Project uses TypeScript over Concerto types (with Concerto also compiled to TypeScript) to provide type-safe logic/calculations for templates; ensuring that a wide array of programming errors are caught at template compilation time, not at runtime. #typesafety #soundness #typescript #templating #legaltech

17

2 Comments

This year I decided that I'll talk more about software testing, especially TDD and automated tests. Today I want to talk about the ability to incrementally view the design of a system shape up as you do TDD (Test Driven Development). It's an interesting visualisation exercise. 🥋 When there's nothing, you start with simple definitions and your tests reflect that. They might be simple tests to to check if a function is defined. As you incrementally build the system, the tests get more nuanced and complex. There are mocks, test datasets, fixtures and several other testing mechanisms weaved into the "tests fabric". Together, all of this, or the test fabric as I call it, is a blueprint of your design. This is a valuable insight because once you understand this, you will be able to spot "cracks" in your design. As we continue to add tests and refactor existing ones, several design decisions become intentional & conscious. These decisions tell us about the building blocks of the system. They provide insight into the behaviour & implementation of the system in a compact, clearly specified manner. At any point, simply reading the test cases is like flashing a bright light on a dimly lit architecture diagram that resides in our minds! While I describe this feature in terms of a TDD workflow, the same insights can be derived even if you don't follow TDD. Being able to visualize the design of a software system via it's tests is a feature of automated testing itself! Let that sink in and remember this the next time you work on a project. If you join a startup and there are no tests, write them! (Topic for another day!) The next time you write tests, pay close attention to your design and how the tests subtly, and sometimes, quite evidently impact it. These small, simple acts of observation and reflection can take you a long way in your craft. What are your thoughts? Let me know in the comments section! ✨ #SoftwareCraftsmanship #TestDrivenDevelopment #TDD #SoftwareEngineering #Programming #AutomatedTesting #SoftwareDesign

4

2 Comments

Interesting article. I firmly agree with the task breakdown and implementation detail. Has anyone tried using number of tasks and average rate to project timing?  https://lnkd.in/e_HysuiJ

10

1 Comment

I've written a short blog post about MVP's as I'm a big fan of them (done right). What does an MVP mean to you? I'd love to hear your thoughts!   #mvp #agile   https://lnkd.in/gP2XFfxn

7