Steven Stuart

Silly takes like this make me worry about our future as an industry. Clean Code is one of the more timeless works in our field - and Uncle Bob’s thinking in the space has done nothing but get better with the passing of time (the articles in his blog in the years since CC have been gems). I for one am excited to hear about polishing up (refactoring?) Clean Code to remove the few dated bits that are in it. More importantly - as a field, it’s important that we begin to grow up and recognize that there *are* timeless principles that underpin software development, even as you install your latest version of Rust. If memory serves, Martin starts Clean Code with a prelude comparing his coding recommendations to martial arts styles. That is, in a given style there are things that are right or wrong *for that style*. Which is far softer than I think is the underlying truth. That is, calling him absolutist is absurd.

17

11 Comments

Measure what matters. I've written a 1000 lines of code before, demonstrated it, and then never touched it again. I've written a line of code that gets used over, and over, and over. Which is more important? Which hits the metrics? More importantly, which one is incentivized? Find ways to measure impact and outcomes. Everyone will thank you for it. And your software production will be incentivized around what matters.

9

Regarding software engineers the concept of "seniority" seems to be being discussed recently more than before and I wonder why. There seems to be a shift in the industry that companies hiring engineers had raised the "acceptance bar" so junior/medior engineers have it tougher than before to even get past the door (companies want experienced engineers and superheroes only) ... but then inside the companies the hired seniors are given repetitive and subpar assignments yet have no one to train / upskill / support around them. This seems like a short-term cost optimization that will have dire consequences in the future as seniority is built up by collaboration and learning from others (aka mentoring/coaching). Keypoint: The main leverage of more senior software engineers is they can help others become more senior and open up their potential. For that they need juniors/mediors around them and enough space to do so. Just thinking out loud... Anyone willing to share his views? #senior #staff #principal #mentoring #coaching #pairing #mobbing #leadbyexample

16

1 Comment

An RPG leveling tree for Engineering Managers 🧝🏻‍♀️ You can also check out the SWE and DevOps leveling trees in my previous posts. TPM and QA coming soon.

4

2 Comments

Is your team worthy of having juniors? Having a team with people at different levels of experience creates an environment where different strengths and different ways of thinking combine to produce great work and a humane and fun team culture. There is more emphasis placed on learning, teaching, with teachers learning too! This creates solidarity because good seniors are regularly helping out the juniors, so when they can return the favor, they are that much more motivated to help their mentors. Plus it's a well-proven trope in science and mathematics that young people can often have brilliant, even revolutionary, insights even in the early stages of their careers. Yes they require time, so only healthy, successful teams who know what they are doing can be capable of fostering their juniors. The presence of happy, contributing juniors is a sign of a great team. Hire a junior and start on the path to greatness today!

4

Ok, everyone has an unpopular take. Here is mine. Your testing is flawed. All of it. Automation? Flawed. Manual? Flawed. BDD? Flawed. Code coverage? Flawed. Entrance or Exit? Flawed. Performance? Flawed. Environment? Flawed It's all flawed. Why? Because the moment you put something into Production, that is a series of variables you CANNOT duplicate in test scenarios. Because there are dozens of other systems out there that you have to play nice with, and you CANNOT duplicate these in test environments, Because the customer has expectations that the moment you flip the switch, things will work out of the box and everything will sync up nice and everyone will be happy. Until Mary can't get to the Company Payroll systems because no one mentioned that tidbit in Discovery calls. You CANNOT duplicate Mary. And, there is a flaw in this post. Did you find it?

1

5 Comments

Software architects are in a unique position on the team. They aren’t project managers, but architects decide when and how software is delivered. They aren’t product managers, but architects make sure the software meets its business goals. Software architects have a distinct set of responsibilities and are seemingly at the center of everything. #Design_It!

48

4 Things You Should Put in Your Daily Dev Log To harvest meaningful patterns from your dev log, you’ll need to capture the same things daily. I’ve been engineering software for 25 years, and I’ll share what I’ve routinely kept in mine. Your context is different, so your list will be also. Just make sure you capture the same things daily. Use this list as a skeleton to start from. It’s easier when you aren’t starting from a blank page! Pull Requests I keep track of every PR I submit, approve, or merge. Almost any work product I deliver or review flows through Git. My lists of PRs serve as a personal task-level kanban board of work in progress that I am connected to. These help me easily reconstruct a story of what I’ve done throughout the week. Personal Interactions I make note of every personal interaction I have, scheduled or otherwise. In addition to these notes, I keep a page for each person, and I link to that page from my daily notes. As I note patterns of interaction with a person, I’ll describe those patterns on their page. Over time I build a library of every person I’ve collaborated with and what we worked on together. Project Actions I keep a running narrative of the things I’m working on. I keep a section for each thing I’m working on. These might be at the product or story level - it just depends. Each time I hit a stopping point or interruption, I make a note of what I’ve been doing and what I plan to do next. Guess what I use to inform my daily standup updates? Perplexing Puzzles I make a note of everything that surprises me. These could be strange program behaviors, blockers, production issues - anything unexpected. As I review these periodically, I ask myself how I can use what I’ve learned to improve my mental models. Hopefully this list helps you get past the starting line. Do this faithfully for several months and see where it takes you!

8

8 Comments

In the latest Inside Java Newscast, take a closer look at the feature set for #Java23, which is now final. https://lnkd.in/gB4rrEQq

1

Releasing low-quality software is like serving raw chicken 🤢 Bj Muse explains: ❌ Excellent teams don’t deploy software before it’s ready. ✅ Empowered teams take ownership of their work. Hear more of BJ’s thoughts on taking ownership of software development on the latest episode of The Test Automation Experience: 🔗 https://lnkd.in/e-7sqxiJ

13

1 Comment

The state of #JavaScript testing frameworks in 2024: A comparison of CucumberJS, Cypress, Jasmine, Jest, Mocha, Nightwatch, Playwright, and Vitest:

6

In this episode of the Inside Java Newscast, review the full release notes for #JDK23 to see all the noteworthy changes included in the newest version of the JDK. #Java23 https://lnkd.in/d73CrmQg

2

How can you manage a software engineering team when you are not a software engineer yourself? What has helped me immensely over the years: First off, yes, I have an engineering team under my leadership. Of course, I am unable to do code reviews or advise functionally. So how do I do it? A list of points, with some nods to musical pieces. Beyonce, All the Single Ladies - NOT I am not alone in this endeavor. I have co-functional leads who I can ask and get advice from anytime. My work would otherwise be impossible. Vybz Kartel, I Can I used to work in functions that often resembled PO work. Plus, I have worked with engineering teams in close collaboration for over a decade now. So I understand and can steer the dynamics. Machel Montano, Endless Wuk I am capable of understanding the business side. If I know why and where we are going I can translate that to the team and beyond. Lisa, Rockstar Believe it or not - I can put together a couple of lines of code. I have worked on some smaller, private projects before. Do I code in my free time? No. But I have seen what the basic structures are and applied them. Danagog, Hakuna Matata I can listen and listen well. I can advise based on my professional and life experience. I have empathy in droves. I can understand the lived realist of a developer, a PO, a designer, an agile coach. Have you seen or experienced non-technical managers? What was that like? Would you be open to be managed by a manager who is not able to functionally feedback you?

38

7 Comments

Every time 10x engineers come up I think of the times I was briefly considered a 10x engineer by management. There are times I have come through and apparently pulled a big, complex solution out of thin air. I say "apparently" because that's what they thought. They didn't see the weeks of preparation and teamwork that went into a sudden, surprising outcome for them. They started expecting miracles every other day or week. This leads to burnout on the developer's part. Managers tend to think that the developer is holding back after this. They refuse to acknowledge the silent work and painstaking little habits that lead to large success. This situation never ends well. If you want 10x engineers it's likely you would not know what to look for, nor would you be able to handle them if you happened to stumble into one.

3

After a recent call with a hiring manager who looks after a large Java Development team I found it fascinating that they said they see experience with Java Swing as a big plus! In today’s world of microservices, cloud-native applications, and modern UI frameworks, it’s easy to overlook the power of traditional desktop application development. But here’s a perspective you might not have considered: diving into Java Swing can profoundly deepen your understanding of Java. Here’s why: 1️⃣ Core Java Mastery Swing is built entirely on Java. Unlike frameworks that abstract away complexity, Swing requires you to work with Java’s foundational concepts—such as object-oriented programming, event handling, and multithreading. For example, handling the Event Dispatch Thread (EDT) teaches you about concurrency, a skill vital for any Java developer. 2️⃣ Deep Dive into APIs Working with Swing exposes you to a variety of Java APIs—beyond the basics. You’ll interact with packages like java.awt, javax.swing, and java.beans, which give you a broader perspective on how Java was designed to handle GUIs and beyond. 3️⃣ Design Patterns in Action Swing leverages core design patterns such as Observer, Decorator, and MVC (Model-View-Controller). Implementing these patterns yourself in a desktop app makes them second nature, helping you write cleaner, more maintainable code in any Java project. 4️⃣ Problem Solving with Constraints Swing teaches you to work within constraints—like managing system resources efficiently, creating custom components, and ensuring cross-platform compatibility. These challenges sharpen your problem-solving skills, making you a more versatile developer. 5️⃣ Understanding Backward Compatibility Java Swing applications remain functional across decades of JVM versions. Building with Swing helps you understand Java’s philosophy of “Write Once, Run Anywhere” and gives insights into why backward compatibility matters in enterprise environments. Swing might seem “old-school,” but the lessons it offers are timeless. If you’ve never built a desktop application, give it a shot. You’ll come out the other side with a deeper understanding of Java’s capabilities—and an appreciation for how far the language can take you.

16

5 Comments

There is no doubt in this fact considering the better features we have experienced when using Playwright like async awaits, no promises, checks retry, better debug, single API, complement dev workflows, using websocket protocol for faster execution, browser context for isolated test execution, supports cross domain like in case of SSO redirection, parallel execution...

5

Salary aside, these are the 3 most common questions I get from software engineers open to exploring a new role: 1️⃣ What’s the tech stack? 🛠️ 2️⃣ What’s the company’s product? 🚀 3️⃣ What’s the work arrangement? (remote, hybrid, in-office) 🏢💻 What other factors do you consider essential when evaluating a new role? Drop your thoughts below! 👇

6

1 Comment