John Laswell

Should the entire development team attend all of the sprint events? No, because it’s inefficient and a waste of time. Right? Years ago I battled a tough client who didn't want the developers to attend the Sprint Review. He wanted them to, in his words, “just keep coding”. I argued…how will the team learn about what the customer and the business needs? His predictable answer was “better requirements documentation”. Software engineers are professionals who need to deeply understand the problems to be solve. The intent of sprint events is to provide context for these problems and enable collaboration. Ask your developers if they are receiving value from sprint events. If not, don't exclude them. Fix the events so they enable the development team. #scrum #agile #collaboration

2

My quick tip if you're interviewing for a CTO role: If you'll be the ONLY engineer on the team... It's not a CTO position. 😜

94

49 Comments

Wow, it's time for that big decision again. Should we create the software ourselves or buy it from a provider? This is a frequent concern. Every project, every new feature like adding live collaborative components, needs vetting. You'll likely hit up Google, type in "WebSockets" and start figuring out how you can integrate this into your software. You'll do some homework first, of course. You'll check available open-source software options and contemplate whether to host it yourself. Or, you'll mull over the many vendors out there. Picking and choosing from them based on what they offer can feel daunting. Let's say you want your app to have a chat feature. It's crucial to keep users engrossed and coming back for more. By having a chat feature, your app engagement, and consequently your business, could see growth. So, what to consider when deciding? You could either pick a vendor that can provide such an API or install some open-source software. You'll need to keep maintenance, growth potential, and scalability in mind. Let me use PubNub as an example. Weighing the build versus buy decision? PubNub offers two clear choices. In-house is not always the win-win situation. It drains developer time. Plus, building a solution that a vendor can provide you at a lower price just doesn't make financial sense. You pay less for both the initial cost and following maintenance with PubNub as your vendor. That's why most software is bought from vendors. It's either via an API or as a web portal front end. All are available, from HR to finance to team management. The majority bought is from vendors. Often, the need for extra resources for this kind of project is overlooked. If working in-house, you'll need six developers on a full-time basis for six months. If you have fewer, the timeline to market stretches. The DIY option might lead to a loss of potential revenue and business growth. This lost opportunity cost comes with the in-house terrain. On the other hand, reaching the market quickly increases business growth trajectory. So, decide wisely. #softwaredevelopment #buildvsbuy #businessefficiency

15

4 Comments

James Stanier has a good argument for why deadline-driven development is so… difficult → https://lnkd.in/gz3rvj2s “Given that non-technical people don’t understand why software is hard, dates become the stick that they beat you with when you don’t deliver on time. Don’t ask me why, it’s just human behavior. I’m sure you’ve done it when roadworks have taken longer than were specified on the sign, or if a delivery of a package was late. Dates mean something to people, so handle them with care. In fact, perhaps we could do something entirely different instead.” What’s the “something different”? “So, instead, you should take a forecasting approach that follows the uncertainty curve that we outlined above. You start wide, and you taper in. At the beginning of a given project, you might even just have the year that you’re aiming to ship. Then, as you progress, you can start to narrow it down to a quarter, then a month, and finally a specific date.” This is why I will always advocate for time horizon roadmaps → https://lnkd.in/gN8VSYZc

13

What's the real cost of not involving developers early? ...Yes, involving developers early means more meeting hours. But the cost of NOT involving them? ↔ Constant back-and-forth clarifications ⏳ Rework and delays ⛓ Team disconnection 😑 Frustration ❓ Anything you'd add? Question for you Product Leaders out there: What's the costliest 'hidden' expense you've seen from leaving developers out of early product discussions? Do you agree that we should involve developers early on? What positive examples have you seen from involving developers early in the product process? Thank you so much to Eric Cussen for enriching our recent webinar. #ProductManagement #Agile #Leadership #ProductDevelopment #EngineeringCulture #ProductStrategy

15

Rails 7.2 now makes sure jobs get enqueued after the current database transaction is committed. Previously, your jobs would run before the records were saved to the database causing errors, so Rails takes care of it for you. If you've ever had to remind yourself (or your team) to use `after_create_commit` callbacks instead of `after_create`, this solves that problem. ActiveRecord uses transactions behind the scenes, so it's an easy mistake to make. And with jobs being retried, it's confusing why the job fails then succeeds a second later. This is another great example of conceptual compression in Rails! https://lnkd.in/gyNtiPnr #ruby #rubyonrails #rails

141

9 Comments

This has to be one of the best ways I've seen to explain why it's important to prioritise good engineering culture and practices. Give engineers the conditions they need to do good work or you'll end up delivering a giant load of poop to the customer.

33

6 Comments

I find Mark's prediction about mid-level software engineers becoming obsolete by 2025, or signals from other companies like Salesforce on total freeze for hiring software engineers, both fascinating and a bit concerning [watch Matthew Berman's commentary - link in the comments]. The biggest challenge I see isn't just job displacement - it's the learning curve. AI is most powerful when you already have the expertise to catch its mistakes. So sure, people who are middle level have already strong foundations to apply their skills elsewhere and redefine their jobs - most likely in amplifying outcomes of the work they've already been doing, now with the use of AI agents. But how do new developers build that foundation if they're immediately relying on AI? It would be like trying to learn a language solely through a translation app. You can fake it only this far. How do we maintain code quality when fewer humans truly understand the systems they're building? The debugging process becomes exponentially more complex. What happens to career progression? If we remove the middle rung of the ladder, how do junior developers gain the expertise needed to become seniors? And how do we ensure AI remains a tool that enhances rather than replaces human understanding and makes us lazy and stupid? For those considering software engineering now, I'd strongly encourage focusing on systems thinking and architectural design - skills that AI still struggles with. Learn to read code critically and understand why certain solutions work (or don't). I think, ultimately the future isn't about competing with AI - it's about mastering the skills AI can't replicate: critical thinking, system design, and problem definition. This has always worked to our advantage across centuries and pivotal moments liek the Industrial Revolution, so I hope it will continue to do so (and the dark scenarios from sci-fi movies about AI taking over won't come true 🤞🏼🫠). PS. I actually explore these themes more deeply in my recent #hankka post "When to use AI, and when to avoid it (and how I use it)" where I share practical strategies for using AI as an amplifier rather than a replacement for human expertise [link in the comments].

15

1 Comment

On the flip side, many teams configure an excessive number of alerts, often with overly strict thresholds. A significant portion of these alerts are non-actionable, leading to alert fatigue. The common response becomes: 'These alerts are expected,' or 'They’ll self-resolve.' However, effective monitoring is only valuable when alerts are actionable and tied to clear resolution playbooks. Without this, alerts become noise rather than signals, undermining operational efficiency.

8

"You can have a great strategy for the next billion-dollar developer product, but the battle is won in the trenches of daily iterations." I love this clip from Lee Robinson (VP Product, Vercel). Lee helped scale Vercel to 1M+ developers and has some of the clearest thinking of developer marketing that I've read. We talked about: - Getting into the developer's mindset - 3 pillars of a great developer experience - Why developers don't trust your marketing A few quotes from Lee: "Most developers don't adopt a tool the first time they hear about it. It's probably the 10th time." "Great documentation is great writing. The tech industry is plagued with jargon and fluff. It would be much cleaner if people wrote more like how they talk." "The battle is won in the trenches. It could be a two-paragraph docs change or a small UX improvement. For every developer that complains, 100 more won't say anything." 📌 Watch now: https://lnkd.in/g-g-u3E5 Also available on: Apple: https://lnkd.in/grhhYVyh Spotify: https://lnkd.in/gGyvBKmX Newsletter: https://lnkd.in/gGkkYG4M

115

3 Comments

Great observation from a Senior PM currently on the job market: "the roles where they highly value domain knowledge I find to be not very versed in product and just go for what they know." When you don't understand the value of product you revert to looking for domain experts.

109

25 Comments

2025 hot take: I'm not sold on Test-Driven Development (TDD). After years in the industry, I’ve seen few teams fully commit to TDD and even fewer stick with it long-term. I’ve been on teams that have completed projects with TDD and ones that started with TDD but dropped it when it became more of a blocker than a boost. The biggest untold truth? TDD success stories often come down to survivorship bias. The teams that succeed with TDD would likely succeed without it, too. Why? Because the teams that have the most success with TDD are usually made of senior engineers who’ve built similar systems countless times before. Here’s how I see it: If you’ve studied for a test so well that you could write both the questions and the answers before you take it, you’re going to ace that test no matter what. In essence, TDD works best when you already know the answers. But really then TDD isn't the main or even a contributing reason for a project's success. What do you think? Is TDD overrated or am I missing something?

366

327 Comments

Q: "How do I know if my team is delivering secure software? I’m a non-technical founder without the budget to hire consultants." A: Well, you can’t know for sure. If you don’t know what’s good, you can’t know what’s bad either. But you’re not helpless. It’s quite safe to assume that your average general-purpose developer will deliver similar quality across the board. A sloppy developer will be sloppy regardless of what they do. It’s not likely their approach to security will be spot on, but it’s only the quality of the frontend that’s terrible. So if you’re not sure about security, take a look at other, more relatable parts of their work and do the guesswork. It’s unlikely you’ll be very far off. Talent is only one piece of the puzzle. The other is character. The character and job habits of people working for you are a good proxy for overall quality. I had this guy who wasn’t really good at certain development concepts, and his code reflected this struggle. On the other hand, he always delivered properly tested, stable, solid work, and on time. His character didn’t let him send off stuff he wasn’t happy with. As a non-technical founder working with tech teams, you’re always in a situation of information asymmetry. Some dudes are working for you and telling you stuff you have no idea about, and you have no choice but to trust them. You can’t bridge that gap with knowledge - at least not quickly. But what you can do is look at the problem holistically, listen to your gut feeling, and go with it.

7

3 Comments

When engineers say "no," it reveals flaws in your pitch or opportunity, helping refine your approach Here are a few common mistakes 👉 𝗖𝗼𝗻𝘁𝗮𝗰𝘁𝗶𝗻𝗴 𝗽𝗼𝘁𝗲𝗻𝘁𝗶𝗮𝗹 𝗰𝗮𝗻𝗱𝗶𝗱𝗮𝘁𝗲𝘀 - 1. Not including basics things like work location, comp range, and tech stack 2. Not highlighting what makes the role/company relevant for them 3. Targeting the wrong (or not enough) people 𝗙𝗶𝗿𝘀𝘁 𝗶𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄𝘀 - 4. Jumping right into technical questions before creating buy-in 5. Not pitching your company's vision 6. Not understanding why the candidate is interviewing and what they're looking for in their next role 𝗟𝗮𝘁𝗲𝗿 𝘀𝘁𝗮𝗴𝗲𝘀 - 7. Assuming candidates are interested, without understanding their decision framework 8. Not debriefing and addressing concerns after every interview 9. Extending offers without pre-closing Good recruitment involves a lot more than just finding top talent Have a great weekend!

8

1 Comment

Struggling with efficiently managing your software engineers for your company? Wish you had a way to retain your best engineers and get your projects delivered on time? Let’s chat. I’ve built and run several large teams with the highest retention and efficiency in my divisions.

9

Observation: 9/10 SWE's quit at “reading the docs”. Cut through the BS with this easy trick: Take action and build. Writing code is 100x easier than the docs make it sound. “Reading the docs” gave me crazy imposter syndrome: -Git -WPF -Kafka -OAuth -Angular -GraphQL -RabbitMQ -Kubernetes In ALL cases, I conquered my fears by building. Except for WPF. I gave up on that. And Kafka, that's for another day. Forcing yourself to build/code/deploy melts analysis paralysis. Then you'll say "oh that was pretty easy". Trust me, we aren't building rockets. Practice AND Study build true mastery.

22

1 Comment

This is hard for some people to hear but... Your software is never going to be perfect. That doesn't mean that it can't be amazing and useful and awesome. But perfect isn't on that list. So instead of trying to spend all of your time picking the perfect tech stack, the perfect architecture, the perfect time for the stars and planets to all align... Just. Get. Started. Make the best decisions you can now, get started, learn, and evolve. 👇Check the comments for the full video!👇 ---- 🎬 Check out Dev Leader on YouTube for multiple full-length videos weekly! 🗣️ Share with your network! #softwareengineer #softwareengineers #softwareengineering #softwarearchitecture

25

3 Comments

🛠️ Okay y'all, looking for advice: I'm running a handful of small apps for Build Carolina's Development Studio initiative. These are low-utilization apps for relatively small audiences. I'm leaning heavily on Rails at the moment but expect to bring on some JS-stack projects in the near future (likely Next, but I'm always open to the flavor of the week in JavaScript 😅) Here's what I'm finding for hosting: - I still know Heroku best, but I just don't trust them to not enshittify further. 🫠 Every new app here is a liability when Marc decides he needs another island or whatever. 💰 - I'm using a lot of Render and like their devex philosophy, but their pricing is weird (per-service + premium tiers? Pick one!), the big feature gaps in their platform have gone long-unaddressed, and their support has been poor. 🤖 - I'm experimenting with Fly.io: great pricing, but a weird mix of UI-vs-CLI workflows and segmenting project resources is unintuitive. I feel like I'm going to wake up to a huge bill because I accidentally over-provisioned something here. 💸 I'm curious what other folks are doing for small-scale artisanal app hosting in 2024+. Are we all running our own EC2 clusters? Is everyone just writing Next apps for Vercel? Maybe I'm just an old fuddy-duddy looking for a backend host in a static SPA world. 👴 ❓ Tips/tricks/tales welcome. Where are you hosting your lil' bytes right now?

13

39 Comments