✨ Pervez Choudhury ✨

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.

33

14 Comments

this is a really important point. Of course it's allowed! the only people I have met with that interpretation of tdd are people who have been forced into it by people who think it's the simple act of writing tests first that matters rather than the mindset that makes you realise doing otherwise is likley play. I think it's really important. When code works according to the spec we should be allowed to ship it. that doesn't mean we are finished - just hit the bare minimum standard. Then we should be allowed to invest more into it and ship it again, and again. This whole madness and obsession with tickets gets in the way of the feedback loop of determining value, shipping and exploration with the consumer of the code. The tests are the *most* important part of a codebase. I can rewrite code but I can only rewrite tests whilst the domain knowledge is clear in my mind. Tests are the source of truth for the behaviour of the system. After that point I depend on the tests to replay it to me. So refactoring and development of tests is a noble persuit that I think many teams and engineers undervalue.

1

Some software engineers never get the opportunity to work closely with customers. When I sat down to talk with Jade Wilson, it was great to hear that her and her team DO spend time working very closely with customers. In these interactions, Jade and team get to work alongside the development team of the customers to prove out if Microsoft technology is a good fit for what they're trying to accomplish. As you might imagine, being successful at this is NOT just a matter of being highly technical. These engineers have to have very good communication skills and really focus on what the customer is trying to achieve. A whole interesting set of constraints! 👇 Check the comments for the full video 👇

19

8 Comments

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.

292

54 Comments

Too many 'software engineers' today are glorified code monkeys. Harsh? Maybe. True? Absolutely. - 90% can't explain how their code runs in production - 95% have never touched a database outside their ORM - 99% think 'infrastructure' is someone else's problem News flash: AI is coming for your job, one-trick pony. The future belongs to the curious. The explorers. The 'how does this whole thing work' nerds. Why? Because they'll be conducting the AI symphony while you're still tuning your one-string banjo. Here’s 4 signs you're on the endangered list: 1. Your knowledge of DevOps doesn’t go beyond merging your own PR 2. You've never SSH'd into a server (it's not a disease, I promise) 3. Your debugging process is 'console.log' and pray 4. You think scaling means adding more if-else statements Embrace curiosity. Break things. Ask 'why' until your team wants to mute you on Slack. Because in the AI future, the curious engineer doesn't just survive. They thrive. P.S. If this post made you angry, you might be a code monkey. Don't worry, there's still time to evolve. 🐒→🧑‍💻

145

45 Comments

Interesting investigation of transaction cost of Pull Requests by Dragan Stepanović with Dave Farley Continuous Delivery Ltd Interesting with some data about: * 10 lines of code => 10 issues. * 500+ lines of code => LGTM :-D == Impact of Pull Requests on Work/Wait ratio == Wait time in processes, is the time it takes for work to wait at a station/gate before moving forward. A pull request is such a station. This wait time is what we want to reduce in Lean. And want to reduce in Agile methodology. This translates to ratio for time to make a change and create a pull request vs. wait time to get it approved and merged. As an example. If a change takes half an hour to make, but 2 hours to get approved, that is a ratio of 1/4. This means tasks are waiting by a factor of 4 to progress further. Or, viewed from a different angle, developers potentially getting a WIP factor of 4 to "keep busy". (Note that the best work/wait is ∞ or wait/work ratio is 0 which is more useful) The are many different goals and means that work counter to each other. A complex system of interdependent watt governors. To improve the work/wait ratio, require more frequent interruption of work/flow of team members. To lower the impact of the wait (and keep "producing") requires more WIP, which increases risk of and frequency of merge conflicts as well as inducing burn-out and decreasing quality of work. The bigger the Pull Requests are, the less valuable the review. The smaller the Pull Requests are, the worse the effect is on interruptions and on parallel WIP. The worse the Work/Wait ratio is - the slower the iteration speed and feedback cycles become. I.e. opportunity cost and impacts ability to deliver. Pull Requests should AT LEAST have net positive value of the expected benefits from reviews, quality increase, impact on burnout, opportunity cost, quality decrease, bugs, incidents, and Software delivery performance in general. I believe Pull Requests have a considerable net negative value, when all these aspects, unintended side effects and impact on work and people are taken into consideration. Which they should. To paraphrase Jon Arild Tørresdal: "If you and your team do not notice friction with Pull Requests, you are not moving fast enough" A way to reduce the negative impact of reviews is to strive for for a non-blocking review approach. This can be done by: * tool support (e.g. reviewing each commit individually on the reviewers own schedule - but without blocking the committer). * doing holistic review sessions of code walkthrough * doing pair programming when appropriate and meaningful. Here is a more in depth write up about removing blockers and friction: https://lnkd.in/dcBiZWdG And a bit more in depth tirade about pull requests: https://lnkd.in/d9bs77uK https://lnkd.in/dueY4Bkx

57

14 Comments

🔥🔥🔥amazing software engineering posts from the past week🔥🔥🔥 Ryan Murphy rejection means only that: rejection. Keep going. https://lnkd.in/ecfy5tBV Tiger Abrodi consistently posting TypeScript knowledge bombs https://lnkd.in/ebeapvQ9 Taha Hussain are you fueling the micromanager in your life?? https://lnkd.in/eFtrhiHN Eric Roby please keep your processes simple! your success depends on it! https://lnkd.in/epk7Q_qJ Owain Lewis principles for a delegation: I needed this 2 years ago. https://lnkd.in/eNvt564u Pramoda Vyasarao master the basics https://lnkd.in/eMKTMesj Matt Watson new, "exciting" and complex tech excites only one person: the person who uses it to build. long term success needs tech that is boring, known and comes with a talent pool. https://lnkd.in/e8aK9aQt Austin Belcak above average results require above average effort. Go the extra mile - the road is never crowded. https://lnkd.in/edWQGDPH Francis Nayan take. action. today! https://lnkd.in/ej-HbcpJ Callie Buruchara 7 principles for giving feedback. it's easy to see that Callie is leading from experience! https://lnkd.in/e9XXnDyq

29

When everybody tells you that feature isn't necessary ... and it end at the bottom of the backlog ... but it's such a great idea I’ve been frustrated by that I don’t know how many times I’ve been doing code for decades, and I saw easy wins Yet everybody was focusing on something else Then, I understood the purpose of software It’s to help businesses earn more money Not to solve each and every problem I love automate everything Making processes as smooth as possible But there is a point where engineering can’t help As the joke about taking a week to automate the 30s process Let’s do the math together A feature can save 15 minutes of employee time a day I need a team of 4 devs to deliver it in a week Four employees use the feature → I will save 240 hours a year for the four people team → I need 50 hours of the dev team’s time to deliver 4 devs week on average £100k is like 1 dev a month 💸 The development cost is just under £8500 4 employees on average £50k will save 240h 💰 The annual saving is £6250 The return on investment will come after a year The salaries for the people mentioned are £600k a year The company's revenue must be in millions £6000 makes no impact If you get frustrated about problems not being fixed It may be they aren't worth solving If you want problem solved Do the math, show where the money is That's how you prioritise well

15

21 Comments

Developers: Why are you using an old laptop? I did the maths on my work laptop. It’s a reasonable spec, that I’ve had since 2022. M1 Pro, 16GB RAM / 512 SSD and is 2 years old. Buying new equivalent, M4 Pro 24GB RAM / 512GB SSD would cost around £2k. Currently you can get the same model on backmarket for just under £1k. That would mean the cost of replacing is £1000 over 2 years which works out £10 per week or £2 per day if you account for working days. My pre tax daily cost to the business is around £300 per day. Split that over 7.5 hours is £40 per hour. Or 75p per minute. I run my test suite multiple times a day and it can take maybe 5 minutes a run for the full suite. All I need to do is for my laptop to save me 3 minutes a day in run time, for it to cover the £2 per day it costs to upgrade. There's no environment impact if you sell your laptop on or feed it down the chain to someone who doesn't need the power. So the question is, apart from being attached to your laptop like some panini sticker album, why would you not upgrade? #prodeveloper

73

196 Comments

Developers.... Can someone explain why SRE acronym has been hijacked as the moniker of the Software Engineer? According to https://lnkd.in/e2Wj2kCy - SRE stands for Site Reliability Engineer. Whilst this and a Software Engineer role may overlap, the first is not the second and the second may not be dealing with Sites at all. If you have that role or are a software engineer that uses SRE, can you explain what it means and why you have it.

5

2 Comments

I was recently finalising the migration of a clients iOS app from Xamarin.Forms to MAUI but needed to test it on older iOS devices such as the good old iPhone 6s. Having one of these to hand I thought it would be a simple case of charging it up, plugging it in and I'd be off to the races - but no ... that's not what happened. I believe that in an effort to keep the size of their development IDE Xcode as low as possible (and probably for support reasons) Apple quite reasonably prune out the components that targetting previously supported devices that are now condidered to be redundant. Fair play, but what happens when someone wants to use Xcode to debug an app on a device that is no longer supported? Well, it turns out it's not as major a problem as you might imagine and in an effort to save me from having remember how to do it again I've put a quick blog post together. https://lnkd.in/eNxEMhZN #mobile #development #maui #xamarin #xamarinforms #migration #testing #xcode #blogpost

3

2 Comments

"reforms should not be made until the reasoning behind the existing state is understood" Chestertons Fence This philosophy is incredibly relevant to career developers. Developers cannot take anything in an application at face value. Something that seemingly is no longer relevant or used in a piece of software may be the one thing holding the entire thing together, this is especially true for legacy applications where assumptions may have been made about the application state. In these scenarios, it's easy for a developer to discard a piece of code they deem as "Tech Debt" - When in actuality they are removing a core piece of the puzzle. Developers should exercise extreme caution when removing code from an application, especially legacy, poorly tested, applications where failure may not be immediately obvious. Chesterton's Fence teaches us that until you can explain the purpose of a piece of code, you should not remove or make changes to that piece of code. https://buff.ly/447oCfV

4