Conrad Gray

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

lateinit and lazy in Kotlin Imagine you’re at a party 🍕, and you tell your friend, 'Bro, you’re on snack duty, but don't bring them right away. We’ll call for snacks when we really need them.' That's lazy in Kotlin! You don’t initialize a variable until it’s actually used. It’s like telling your code, 'Hold up, I’ll get to it later when I need it.' val snacks by lazy { fetchSnacks() } Then there’s lateinit – it’s like inviting a DJ 🎧 and saying, 'Yo, I’ll tell you where to set up later, but trust me, I’ll need you.' Here, the variable is initialized later in the code but must be initialized before it’s used. lateinit var dj: DJService In short: Lazy: 'Bring the snacks when I need them.' 🍿 Lateinit: 'I’ll set up the DJ before the party starts, but not just yet.' 🎶 Now the next time you see lazy or lateinit in code, you know they’re just like party prep! 🎉 #Kotlin #LazyVsLateinit #CodingAnalogies #AndroidDevelopment #DevLife"

12

1 Comment

Returning to Java from Kotlin has me thinking again about nulls and null-safety. Kotlin has softened me somewhat on the subject of nulls, because its handling of them is safe and elegant: declaring a type as T? is more or less equivalent to declaring it as Maybe T in Haskell, and null is just a compact representation of None in that case. The compiler will simply reject anything that tries to pass null, or the unchecked value of a variable of nullable type, to a non-nullable receiver. It's one of the two things about the language I'm really going to miss (the other being the Ruby-like block syntax). After a phase of thinking Optional<T> should be used to do the same thing in Java, I'm actually swinging back more towards annotating optional fields and parameters as @Nullable, and relying on tooling (the IDE, build-time linting) to enforce Kotlin-like null-discipline. But there's a skeleton in the closet: older (pre-record-type) Java often has a lot of POJOs with default no-argument constructors lying around. You construct one, everything's null, you set fields one by one with the setters. It's much harder to impose null-discipline of any kind in this scenario. People depend on this behaviour, too - they create test value objects by newing up instances of POJOs and setting only the fields the code under test is interested in, and everything works. You can say "you should make it impossible to construct an object in an invalid state" all you like, but you're going to break all those tests if you actually take the ability to partially populate a value type away from them. Lombok doesn't help, either - there's no way to compile-time check that all the mandatory fields have been added to a builder before calling build(). And even with record types, the ability to use builders to supply field values by name, rather than relying on their order in the constructor signature, is going to be hard to take away from people working with value types with a dozen or more fields. Java is just an ever-burning tire fire around these issues, and always has been, and it's a major reason why "legacy" code tends to suck so much. At the moment the best I think I can do is try to promote a general pattern: if you can't ensure correctness on construction, validate correctness immediately after construction (and prevent illegal mutation after that). At least then you can eliminate ad hoc null checks downstream of validation, and be clear about when missing values are actually to be expected.

83

34 Comments

Struggling to land a job as a Software Engineer with 0-3 years experience? Here's how to shoot to the VERY top of the pile: I won't BS you, the junior market is brutal right now. There's very few roles, and I've been hearing stories of adverts getting over 1000 applicants... So how do you stand out? The truth is, out of those 1000 applications, only 20% will be in Australia, and only 20% of those will be software engineers. That's 40 people. No hiring manager wants to interview 40 people. Especially when very few of those 40 will have the right communication skills, attitude and aptitude to get through the interview process. In fact, 99% of hiring managers would prefer to interview just 1 person. Do this, and that 1 person could be you: - Prepare some personal projects (to show willingness to develop skills) - Do some research on the company (to prove genuine interest) - Practice communicating (poor communicators fail interviews) - Apply with CV + personal project links (so you can be found easily) - Identify specifically why you are a good fit (if you don't know, nobody will) And then - CALL THE HIRING MANAGER. Or video message. Or voice note. In 30 seconds you can: - Introduce yourself and say that you've applied - Reference the personal projects on your CV - Mention why you like the company and why you'd be a great hire - Give availability to discuss the role further in an interview - All whilst proving you are a strong communicator with a great attitude Do this well and you'll be a 1/1000 candidate, I promise you.

45

3 Comments

Programming tests are: ❌ Often stressful ❌ Take-home tests are usually time-consuming ❌ Rarely representative of the approach and conditions of the job that they're testing for ❌ Many times online code testing platforms will penalise you for clicking away from the screen and sometimes they penalise you for any copying and pasting ❌ Usually theoretical "best practice" based - showing how you might do something if you were working in a vacuum, not accounting for business needs / interdependencies with legacy platforms etc ❌ Typically they favour those who have more recently come from education over more seasoned professionals ❌ In some cases the results are ignored or overlooked anyway if the candidate has done well enough in interviews rendering the test itself pointless ❌ In other cases companies take a "line in the sand", "computer says no" approach where even someone who is a known entity to the team or business will be rejected if they don't do well enough on the test   I have NEVER heard a developer say that they enjoy technical tests.   Some of the most senior, capable, accomplished developers I have worked with refuse to complete them as part of a process - particularly timed ones.   How often do you write code in a real life production environment with a timer counting down? And when would you ever want your team to not have access to Google or GitHub or Stack Overflow on a difficult task? A significant part of an Engineer's role is to research potential solutions critically, not to be a walking programming encyclopedia!   Even if your test is a less pressured, more representative take-home task rather than a recorded or monitored time-pressured task, they're not always that informative and they often take up a large chunk of time, which, particularly for someone who is currently in full-time employment and interviewing for multiple other opportunities, is a lot to ask. They also often lead to excellent candidates withdrawing from the process.   To quote a senior dev I spoke to the other day: "It doesn't matter how great the pay or the company or the work are. I'm a professional with over 10 years' experience, treat me like it. Don't set me bullsh1t homework"     👉 So why is it that so many interview processes use them? 👉 And what are the genuine legitimate alternative approaches to be able to ascertain someone's technical capability?   Keen to hear your thoughts Linkedin? Futura Talent #technicaltesting #techrecruitment #developerlife #softwaredeveloper #softwareengineer

8

2 Comments

Talking with loads of #ios and #android engineers and leaders since my return from holiday last week. It seems there's still lots of questions around how long will it take the market to pick up! I'm getting asked 'Is it just the iOS market that's slow?' Err no, certainly not. 'Will the Android market pick up this year?' I don't have a crystal ball, but I do have optimism. "It cant stay slow forever!" I reassure them. There will be a bounceback! Let's talk..... When do you think the iOS and Android recruitment market will pick up? Are you already seeing the greenshoots of recovery? Have you got some inspirational words of positive stories to share with your fellow devs? Please let me know when you're commenting whether you're in the UK, Ireland or Europe! #androidengineer #iosengineer #uktechjobs #mobileapps #bounceback

15

4 Comments

Oh man, jumping back into #Angular after a few years (I still mostly work on #AngularJS legacy apps), requires a lot of cleaning-off of mental cobwebs. This set of routes literally took me 2-hours to design. I keep forgetting that complex routes can map to sibling components (not just nested components). I'm looking forward to seeing if I can get this to work proper with lazy loading of the route trees. This morning's episode of Shop Talk Show with Chris Coyier + Dave Rupert felt very on-point for me. They talked about embracing the struggle. Sometimes, it just feels like there are no "easy days". I'm almost embarrassed that setting up a router isn't something I have immediate muscle-memory for. But, how often do I actually have to do this? Whether it's problem solving or just trying to figure out how to best make use of your limited time, every day has its own kind of struggles. Such a great pod cast. Keep up the great work you two! Episode: https://lnkd.in/ev9SpUXu

3

🎨 A fascinating observation with the Element Timing API (Blink only). I have a client who is keenly interested in tracking key paints, not just the largest one. To help measure them, I’m using the Element Timing API and sending the data off to SpeedCurve. We noticed some oddities in the timings—sometimes, rarely, things are much, much later than we expected. Sometimes whole seconds later than, for example, largest contentful paint. The problem was much more pronounced on mobile. Time to get digging. On desktop, their site is a two-column layout. On mobile, the righthand column sits beneath the main content. An incredibly common design pattern. We were capturing paint timings of content in this rightmost column that was either very much above or very much below the fold depending on your screen size. This was my first line of enquiry: Do element timings fire when the element is rendered *regardless of whether it was on screen*, or do they fire when they’re rendered and in viewport and actually observable? In practice, it turns out it’s kind of a both and sort of neither. 1) Chrome will fire the timing when the element is first rendered regardless of whether or not it’s visible to the user, but; 2) Chrome also (defensively) doesn’t render content until it’s almost in viewport. This means that elementtimings that are way way way off screen (like my client’s) may never fire at all if a user doesn’t scroll far enough, but if they do fire, they’ll fire before they’re necessarily visible. To see this phenomenon in action, I made a super simple demo—scroll this page and keep an eye out for the red paragraph: https://lnkd.in/evuNN5tG

22

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

Here's why I think refactoring as you go is a myth 👇 I think the theory behind this is great - truly. I really do think that teams should be empowered to refactor code as they go, keeping the code base tidy and better than when they got there. But this doesn't work well for every team, and I'd wager this doesn't work well for most teams. Even though I love the concept, I think there's an implementation challenge. And it's because of this reason: Not everyone is aligned on what the business priorities are. This single thing can turn little helpful refactors into development nightmares. I've spent a decade in startups prior to Microsoft. 2 years were as an intern across 6 internships and 4 different companies. 8 years were at one company that I was part of growing from 8 people to 250-300 people. I've (un)fortunately seen some sh*t. I've watched refactoring go COMPLETELY off the rails because developers just made the decision to go do it. It completely crippled teams that were blocked behind an avalanche of refactoring that went on for months. Fixes couldn't go in because "it would need to wait until after the refactor". And it's not like this only happened one time or by one person. If you're reading this going: "That sounds like a TERRIBLE way to refactor! That was improperly scoped. Deliver it in pieces! How could you let that happen!" Or maybe: "That's not what refactoring is. Refactoring is not rewriting. That's a rewrite. You're mixing these things up" ... that's literally my entire point, so thank you for drawing attention to it! I love this idea in theory but in practice it's dangerous as heck UNLESS you have a team that's completely aligned on: - What priorities are - What the team values - How to hold each other accountable - How to communicate clearly with stakeholders Otherwise, we get developers pulling at the yarn to clean things up. But then they have one more thing they need to do. Then another. And then then perhaps the team isn't holding them accountable in the standup. And maybe the product owner feels intimidated or lacks experience to be able to push back. Now we're buried in what's effectively rewriting large portions of an application and having to decide if we cut the losses because apparently there's no way to deliver the remaining parts incrementally. I am not making this sh*t up. I am telling you it because it's real. And I'd rather be real with you and have you debate me in the comments about why you can make this work. Because good: you're thinking about the risks of this and how to implement it successfully instead of just latching onto it being a nice idea. Strive for continuous refactoring! Seriously! Please do! But I urge you not to gloss over the risks that can be associated with it. In extreme circumstances this could completely destroy projects, product launches, and even companies. ---- 📨 Sign up for my email newsletter! 🗣️ Share with your network! #SoftwareEngineering #Coding #Programming

10

2 Comments

👉We have been chatting to a couple of new clients in Germany this week, about using freelance Developers/Engineers outside of Germany (Nearshore), the same questions pop up; ✔How do we know if they are good or not? ✔How much can we save? ✔How quickly can they start? 👀Like anything, there is pros and cons to everywhere, but we have built a network of Freelance Nearshore Engineers who have been rigorously vetted with technical expertise guaranteed, that could save you a 50% reduction on your current freelance rates. If you are interested to understand more about this option and how this could help your business. 🚨Feel free to book a call in my Calendly and let’s see if we can help - https://lnkd.in/eygXyhaz

8

3 Comments

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

The vast majority of candidates that I am speaking with are struggling to get multiple interviews booked in. In this market, it goes without saying that preparation is key to success. Here's 50 interview questions (from beginner to more advanced) that you may encounter when being interviewed for a TypeScript position: #typescript #interview #recruitment #hiring Uneek Global https://lnkd.in/enKjz-zz

4

If you're used to writing tests in a traditional "unit" style where your tests are mock-heavy and test implementation details, it's no wonder you probably think TDD doesn't work well. TDD works beautifully when tests are written against behaviours and not implementation details. Your tests will actually help you make changes over time in this scenario. When your tests test internals and are very mock-heavy, TDD becomes slow and painful, as does testing in general. If every time you refactor internals you have to change loads of tests, and your tests are a pain to maintain, it might be time to reconsider how you're writing them. I don't even use the term "unit" day to day because I think tests written this way cause nothing but harm. Test against behaviour all the way through the stack and your tests will help you.

372

152 Comments

Product-led growth is more than just a trendy term—it's a real game-changer. Here's why it works: 1. Users get to try before they buy. 2. The product practically sells itself. 3. Growth can skyrocket. But here's the thing: it's not just about having great features. It's about crafting an experience so smooth and intuitive that users naturally want to share it. Think about how Dropbox used referrals or how Slack made onboarding a breeze. The result? 👉 Lower costs to bring in new customers 👉 Happier users 👉 Faster, more efficient growth Want to dive into PLG? Start by asking yourself: How can we make our product irresistible from the very first click? Share your thoughts and experiences below! 👇 #productmanagement #productmanager #product

7

6 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

How to 10x your dev team's output: - Implement an emoji framework (instead of replies or threads) - Use screen recording clips (instead of screen-share meetings) - Add comments (instead of feedback meetings) - Write documentation (instead of most meetings) - Use platform notifications (instead of update messages) - Use automation (instead of wasting time not having automation) Implement systems and processes to optimize performance and accountability.

65

14 Comments

How to 10x your dev team's output: - Implement an emoji framework (instead of replies or threads) - Use screen recording clips (instead of screen-share meetings) - Add comments (instead of feedback meetings) - Write documentation (instead of most meetings) - Use platform notifications (instead of update messages) - Use automation (instead of wasting time not having automation) Implement systems and processes to optimize performance and accountability.

121

5 Comments

The secrets of how experienced engineering leaders accelerating growth of new Tech Leads... 𝘔𝘪𝘯𝘥𝘴𝘦𝘵 + 𝘗𝘦𝘳𝘧𝘰𝘳𝘮𝘢𝘯𝘤𝘦 𝘦𝘹𝘱𝘦𝘤𝘵𝘢𝘵𝘪𝘰𝘯𝘴 + 𝘚𝘶𝘱𝘱𝘰𝘳𝘵 + 𝘍𝘦𝘦𝘥𝘣𝘢𝘤𝘬 = 𝗦𝘂𝗰𝗰𝗲𝘀𝘀 𝗠𝗶𝗻𝗱𝘀𝗲𝘁 Individual focus → 𝗧𝗲𝗮𝗺 𝗳𝗼𝗰𝘂𝘀 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗘𝘅𝗽𝗲𝗰𝘁𝗮𝘁𝗶𝗼𝗻𝘀 I love Andy Grove's definition 𝘓𝘦𝘢𝘥𝘦𝘳𝘴 𝘢𝘳𝘦 𝘫𝘶𝘥𝘨𝘦𝘥 𝘰𝘯 𝘵𝘩𝘦 𝘰𝘶𝘵𝘱𝘶𝘵𝘴 𝘰𝘧 𝘵𝘩𝘦𝘪𝘳 𝘵𝘦𝘢𝘮𝘴 𝘢𝘯𝘥 𝘵𝘦𝘢𝘮𝘴 𝘵𝘩𝘦𝘺 𝘪𝘯𝘧𝘭𝘶𝘦𝘯𝘤𝘦. Although I prefer to use the term 𝗼𝘂𝘁𝗰𝗼𝗺𝗲𝘀. It's possible for a team to product a lot of output but not much value! 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗮 𝗧𝗲𝗰𝗵 𝗟𝗲𝗮𝗱? A team scoped Tech Lead can have many flavours. Is team leadership included? What about line management? What about delivery? Clarity is key 𝗦𝘂𝗽𝗽𝗼𝗿𝘁 Engineer → Tech Lead is a tricky transition. Holding more frequent 1:1's initially Seek feedback from team Stay close 𝗙𝗲𝗲𝗱𝗯𝗮𝗰𝗸 We all make mistakes when taking on new responsibilities  Provide both reenforcing and corrective feedback Observations + Impact = Actionable feedback Learn from mistakes Celebrate the wins P.S How do you support new Tech Leads?

9

4 Comments