DEV Community: Steven Diamante

The Most Underrated Skill in the AI Coding Era

Steven Diamante — Sun, 08 Jun 2025 03:25:00 +0000

It's 2025, and I'm advocating you learn how to identify code smells, evaluate software design, and refactor code safely. It's 2025 and coding agents like Cursor, Claude Code, and Windsurf are changing the coding landscape...and I'm talking about refactoring?

Refactoring is the skill to learn in the age of Vibe Coding.

These coding agents have been trained on poorly designed codebases filled with code smells. But here's what I've discovered after three years of deep study in refactoring: this makes refactoring skills more valuable, not less.

The Gap Between Speed and Quality

Coding agents definitely speed things up, but this profession has never been good at slowing down. Typing has never been the bottleneck. The real bottleneck? Design decisions.

I've been teaching others about the power of improving code design through refactoring. Evolutionary design is at the heart of why I practice TDD. Test driven development gives me agility. I keep the design as simple as I need it to be. When new requirements are requested, I refactor the design of the code to easily fit in the new feature.

"Give me six hours to chop down a tree and I will spend the first four sharpening the ax." — Abe Lincoln

Your Design Taste is Your Superpower

My taste in software design helps me evaluate its solutions. When Claude Code generates working code, I can quickly spot the Feature Envy, the duplicated logic, & the overly complex conditionals. More importantly, I know how to coach the agent to fix them.

Try this:

Tell a coding agent to Replace Conditional with Polymorphism and watch what happens. The new models understand refactoring vocabulary perfectly and execute it. They mostly get it right, but bring automated tests to give quick feedback.

Refactoring as Communication

Refactoring and code smells give us a shared language to talk about messy code and how to clean it up. When I'm pairing with another engineer—or coding agent—I may suggest we refactor to a Test Data Builders pattern or we can address the Feature Envy and Code Duplication in the current file.

If you aren't familiar with the language of code design, you'll be less effective when working with others (including coding agents).

From just working to adaptable software

The question isn't whether you need refactoring skills in the agentic era.

The question is:

Do you want to be a developer who can shape and improve code, or one who just accepts whatever the agent produces?

Coding agents give us working code. But working code isn't the same as well-designed code. The difference between the two? That's where your refactoring skills shine.

Experiencing the behavior driven design of using TDD with React Testing Library

Steven Diamante — Fri, 10 Sep 2021 04:28:50 +0000

TDD in React

Test driven development (TDD) is a tool for breaking down complex problems into more manageable chunks. This post will explore my journey of applying a TDD approach to website development using React, Jest, and the React Testing Library. In this experiment, I didn't look at the browser for feedback at all. Instead I got all of my feedback from the automated tests. By focusing on the behavior of the components I'm building, I am able to get a working UI quickly and I'm able to change it's behavior while still verifying its accuracy. Also, I ignore all of the styling until I am happy with the behavior of the system.

The XP Way

When I started programming professionally, I learned it in an XP way. For more info on Extreme Programming check out my article on XP compared to Scrum. My career has always been more than a job. Any product I find myself on, I care deeply about the code, design, architecture, and prosperity of the product. One practice I learned and still continue to, was how to build software through the usage of TDD. Most people have the misconception that TDD is about enforcing tests in our code. But as you will see, it is much more than that.

Why does TDD work?

It is human nature to want to break down large problems into smaller problems. By focusing on the behavior you would like to create you step away from the larger problem at hand. Nowadays, there are many talented developers that are creating life changing software. The breadth and depth that our software products have is immense. By using TDD as a tool, we are about to break these gigantic problems into one question? What is the simplest thing I can do to make this test pass? We use tests to dream up a behavior that we wish our software would do. And then that dream becomes a reality. Some people call it red, green, refactor, but you could just as well call it dream, reality, optimize.

Attempting TDD on Android

When I was on an Android mobile app team early on in my career, I wasn't able to apply TDD enough on the app. Something about having the UI there always distracted me. I would lose that flow that us TDD practitioners love to be in. Too much context switching or long running phases of red will break this flow. On my team, we would always style, design, and add business logic all at the same time. It was way too much all at once. Over time I've learned to break down those different parts of the design process. We weren't using testing libraries that check for the behavior of the UI. Although, we did have some Espresso UI tests that are much like the React Testing Library, those were not a part of our everyday local development. For these reasons, our team, which was actively applying XP practices to a mobile product, was not able to achieve a high level of TDD compared to the backend teams in the portfolio.

Attempting TDD on React

Recently I have been using TDD to generate websites using React and the React Testing Library. Instead of having a browser window open to view my changes, I just execute npm run test:watch which executes jest test --watch. Now, I have a quick feedback loop! And most importantly, LESS CONTEXT SWITCHING! I can dream up some magically behavior I want my UI to do and I can let my automated tests drive towards an optimal design. Most newcomers to the practice don't really understand that at the root of TDD it's all about design. By taking small steps, we only leave the danger zone for short amounts of times. The danger zone being that uncomfortable amount of time where your tests say that your dream and your reality are not aligned. Your software does not work the way you expect it to.

Let's break down my thought process

I want to add new behavior to my website
This is my criteria for what will happen when 'x' happens
DANGER! The software is not in a working state
Do the simplest possible thing to get back to safety

Jest test case

Here's a test case I wrote for a task manager application:

it('should add new tasks when enter key is pressed', async () => {
  renderComponent();
  addNewTask('Take out the trash');
  addNewTask('Write Blog Post');     
  screen.getByLabelText(/Take out the trash/i);      
  screen.getByLabelText(/Write Blog Post/i); 
}
);

And here are my helper methods so you understand what methods I'm using from the React Testing Library:

const addNewTask = (taskName) => {
  const taskInputField = getTaskInputField();    
  type(taskInputField, taskName);    
  pressEnter(taskInputField); 
}; 

const getTaskInputField = () => {
  return screen.getByRole('textbox', { name: /Add New Task/i }); };

const type = (input, text) => {
  fireEvent.change(input, { target: { value: text } });
}; 

const pressEnter = (domElement) => {
  fireEvent.keyPress(domElement, { key: 'Enter', keyCode: 13 });
};

As a user I want to add a task and I can accomplish that by typing my task into the input field and clicking the enter button. This test has that same behavior baked into it. After I wrote this test case I wrote the code necessary to make that happen. Here's a small snippet of the JSX for the Task Manager:

return (
  <div>
    <h1>Task Manager</h1>
    <div>
      <label htmlFor="task">Add New Task</label>             
      <input id="task" name="task" type="text" value={task.name} 
      onChange={handleChangeEvent} onKeyPress={handleKeyEvent}       
      />
    </div>
    <TaskList tasks={tasks} onCompleted={handleCheckBoxEvent} />
</div>
);

Programming is fun with TDD

For me, TDD gamifies programming. I love playing games and when I'm enforcing the practice of TDD it makes it feel like I'm playing a game. It makes programming fun!

Distracted by UI

One reason why I wanted to try this was due to a problem I've been having lately. While working on building a website I am often getting distracted by wanting to style my content before I've even programmed the behavior of it. I'll always have a thought like "oh I want this part to be blue... and now let's make this App Bar perfect!" But hey hey wait, all of that stuff can wait! So I stop and ask myself... What is it that the user of this product wants it to do? How can my website achieve that behavior? This is where TDD in React really shines. By leaving the styling towards the end, we have guaranteed that the application works like we expect it to work. And now we can focus on all of the details of the UI, UX, and A11y, In my opinion, adding styling is more like visual refactoring. The definition of refactoring is restructuring the code to work in a better way without modifying the current behavior of the system. By adding styling to the components last, we are just restructuring the layout of the components that have already proved themselves to exhibit the behaviors we have designed for them. We are giving them color, depth, and space to harmonize amongst the other widgets, text, and buttons on the screen. After exploring TDD in React I discovered an even better way to do it. Outside-In TDD. Maybe next time!

What are the benefits of writing automated testing?

Steven Diamante — Thu, 13 Aug 2020 04:28:08 +0000

TLDR; I am giving a presentation on unit testing and TDD. I would like to know your opinions and experiences with automated testing.

I practice test driven development(TDD) every day at my job. I am a part of an extreme programming (XP) team in a 70 year old company. Other teams outside of our portfolio practice scrum and lack the testing reflex that we all have. A colleague and I are giving a presentation next month to our Java Community of Practice on unit testing. We will talk about its benefits and why developers should write tests. We will also talk about the benefits that writing tests first can have on your code quality. I know the benefits I gain from them, but I would like to hear from this community. If you have never written unit tests, then I would especially like to hear from you. What would you like to know about unit tests? If you dislike testing, what is it that you dislike? Feel free to share any opinions you have on the topic. Thanks in advance!

How I Learn

Steven Diamante — Fri, 07 Aug 2020 03:39:59 +0000

Career Reflection

I started my first software developer job two years ago. I've learned so much along the way and still have tons more to learn. In a career like this, the learning never stops as this is a continually evolving industry. I love new challenges and learning new things. In conversations with fellow developers they have been impressed in my ability to learn quickly and retain information. I've had several people ask me how I learn new technologies and keep my passion for software engineering so strong. In this article, I will talk about how I learn new skills and from what sources I draw this knowledge from. My approach to learning may not work for you since everybody has their own learning style, but hopefully it can give you ideas on how to learn.

I Surround myself with programming

I learn from a lot of different sources and mediums. Of course, I have other interests besides programming, but over the past few years programming has emerged as one of my favorite hobbies. I am lucky to be getting paid for what I love to do. I constantly read, watch, and listen to programming topics. By having different sources of information, I never get bored or feel like I'm over working my brain.

YouTube

I subscribe to many software development content creators. Some present programming tutorials and others talk about soft skills. When I'm bored, I scroll through my subscriptions and add programming videos to my watch later list. Some are focused on technologies I've been wanting to learn and others are cool conference talks. Often times they correlate to one of my side projects or something I'm coding at work. I watch these videos with a purpose. If the video turns out to be boring, too difficult to understand, or disengaging for any reason then I stop watching it. If the content is not benefiting my learning I don't want to waste my time on it. If I still want to pursue the topic I find another video or seek out other resources on other websites.

Some YouTubers speak too slowly for me and if the content is not extremely difficult to grasp I will speed up the video. In the settings of the video you can increase the video speed to up to 2.0x the original speed. I usually will set it to 1.25x or 1.5x and slow it back down for more difficult topics.

I have started my own programming channel called Path To Programming. I am starting with a video series on a Budget Tracker project I am developing.

Teaching someone something that you just learned is the best way to retain information on a new subject. I want to make sure I am getting everything right so it requires me to do more research than I normally would do if I was just hacking away at some project. Publishing YouTube videos and blog posts have been crucial in my development as a software engineer. They also serve as a reference for myself. When stumbling back upon a technology I haven't used in a while I will just read one of my articles to remind myself of how to use it.

Medium

About 6 months ago I started my Medium subscription. I primarily read articles about programming. This way most of the articles that show up in my feed are going to feed back into my learning. Whenever I'm sitting around the house, I like to browse and read programming articles. When I am working with a new technology I will search directly for it. I also enjoy reading Dzone, Baledung, and Mkyong articles. I highly recommend these blogs.

Podcasts

I love listening to podcasts. They are a great source of information while on the go. I have a 45 minute commute in the morning and evening while traveling to work. I am able to utilize that time for my learning as well. My favorite train activity is to listen to podcasts. It may seem strange to listen to a podcast about coding, but it is actually very effective for learning the emerging trends in the software industry.

Here's all of the podcasts I listen to ranked in order of personal preference:

CodeNewbie
Fragmented
Command Line Heroes
Go Time
The React Podcast
Developer Tea
Programming Throwdown
Software Engineering Daily
if/else
Healthy Software Developer
Talking Kotlin
Weekly Dev Tips
The Programmer Toolbox

I recommend you check out at least the top 6. Browse the episodes and choose one that speaks to you. If you are interested in the history of computers and programming then checkout Command Line Heroes. Listening to this podcast gave me so much background on the world of software that came before I joined the industry.

Twitter

I am not the biggest user of social media, but I do browse Twitter from time to time. I don't publish many tweets, but I do read my feed which is mostly made up of software developers and advocates. This gives me information about technology trends, personal accounts from other devs, and access to new articles and videos.

Reddit is an interesting place to say the least. This serves as yet another source of information and public opinion I use to immerse myself in software development. Sometimes I answer programming questions and participate in discussions, but mostly I read articles and memes people have posted.

Here are some of my favorite subreddits I follow:

r/java
r/mongodb
r/ProgrammerHumor
r/programming
r/Kotlin
r/softwaregore
r/learnprogramming
r/React

Projects > Tutorials

When learning a new library, framework, or programming language I like to start by reading an article or watching a YouTube video. When I want to deep dive into a subject I take a Udemy course. Most times I do not finish the entire Udemy course, but I always walk away learning a lot.

One lesson I've learned is that programming tutorials must not be done in isolation. You need to approach these tutorials with a solid goal in mind. If you want to learn a brand new language you can't just watch someone else code in it. You need to practice writing code on your own. That doesn't mean just copying whatever they type. Pause the video and write the code on your own before watching how they do it. If you get stuck then by all means continue the video and you'll learn what you did wrong. This is how the learning sticks with you. When you have that experience of failure, you tend to remember that not by watching someone else continually succeed in a tutorial video.

Personal Projects

I've built an E-Commerce website hosted on Heroku using Spring Boot and Thymeleaf. I built this project with a family member who was interested in transitioning to software engineering. One of the things I learned from this project was how to use Spring Security to enforce authentication via a JSON Web Token (JWT) from the backend Rest API.

I built an Android app for an employee management system. I used Kotlin, Firebase, Koin, AndroidX, and Mockk. I had never used any of those technologies before, but was able to work on the project while learning what I need to learn build the product.

My current personal project is a budget tracking application using MongoDB and Spring Boot for the backend and React for the frontend.

Working on a project would require me to dig just deep enough to get things working. I would learn while trying to solve the business problems of the application. If I did not know how to do something I would watch videos, read articles, and investigate StackOverflow questions until I could solve the problem in front of me.

Programming Books

Published books about programming can often be the best source of information. Books take time to write and are revised and fact checked thousands of times. I was recommended a few books that every developer must read.

Pragmatic Programmer by Andy and Dave

The first edition of Pragmatic Programmer came out in 2000. I preordered the second edition of Pragmatic Programmer last year. I have recently finished it and I know I have become a better developer because of it. This book is about how programmers should think and approach the world of software development. The writers encourage developers to be professionals and masters of their craft. I think I'll be reading this book the rest of my career. That's how useful this information is.

Clean Code by Robert C. Martin

I have recently purchased this book so I cannot comment on the content, but I have heard from developers on how this book changed the way they wrote code. I already love writing clean and readable code so I am looking forward to learning how to do that even better.

Extreme Programming Explained by Kent Beck

This book was given to me when I first joined the company I work for. We use Extreme Programming (XP) so it is required that new developers read this book. Even if you don't use XP it is useful to see how other software disciplines operate. XP is more than just TDD and pair programming. There are values and beliefs that must be upheld in order to be effective in this discipline. Kent Beck has visited our company to talk about programming. He seems like a really nice person curious about learning about people and software.

Multiple tracks of learning

I like to have multiple tracks of work which I can bounce back and forth on. I get bored of doing the same thing all the time. I'm not the kind of person that can watch a tutorial series on a new subject every day for a month. I don't follow any kind of schedule with these things. It's more of an impulse. I never want to feel like I am forced to learn or do something related to programming. If you feel like you are hitting a road block while learning something. Try finding something new to learn. Try reading about system design or practicing algorithms or writing out a TDD Kata. Just find something that reignites that passion and see where it takes you next.

Learn from mistakes

I have made many mistakes in my career as a software engineer. I have learned a valuable lesson from everyone of them. I will make more mistakes. The most important thing is that they should be low risk mistakes. If your Software Development Life Cycle (SDLC) is setup in a way that you can make mistakes in lower environments (like Acceptance or Staging) and fix them quickly then you won't be as afraid to try new things and take risks.

I look back at myself from 6 months ago and think about how much I didn't understand. Some code I wrote one year ago will most likely drive me to refactor it, because it's not written well.

I want to be better than I was yesterday. To do this, I accept that I will make mistakes and that is okay. I will share my mistakes with others so they can learn from my failures as well.

Post mortem

A post mortem is a meeting where a group of people reflect on a major malfunction that happened in their product. My only post mortem was a year into my career when I was an anchor on an API team using a MySQL database as their datasource.

One morning our database crashed and we were not prepared on how to handle it. We did not know the proper people to contact to fix the problem and we were not even sure on the exact location of our database to tell those people where to look. Not knowing that there were better solutions, we as a group decided we would start up a brand new database and start our ETL process to load data (50 million records) from our centralized DB2 datasource. This process took over 4 days to complete. Our Staging application was not functioning for that whole time, which blocked other teams using our API from testing their new feature changes.

During the post mortem, we talked about very detailed events and times that happened during the crisis. The PCF Platform team that manages the database were also there. It gave us a chance to build a working relationship with them and learn from all of our mistakes. By putting everything out there we were able to learn the correct course of action the next time this happens. Our database crashed a month later in production and we were able to get it restarted in less than an hour. Later, we identified the root cause and upgraded our storage capacity. As a result, the crashes stopped happening.

Learn from other developers

I cannot write this article without giving credit to developers that I have worked with. In my portfolio, we pair program everyday and rotate teams frequently. This has given me the ability to work with many different developers. I always ask questions when I don't understand something or see something new they have done. I've picked up a lot of techniques, coding styles, and much more from working with other developers. If you have not tried pair programming, I encourage you to seek out a developer more experienced than you and pair with them on a project. Who knows...? You might teach them something new.

StackOverflow is a website I frequently find myself coming across. When a challenging bug, error message, or library shows itself I will google it and there is StackOverflow with the answer in most cases. But how often have you answered a question on StackOverflow? I found myself always taking from the community so I decided to start giving back. I usually search for Java, Spring, Mockito, Kotlin, and JUnit. I scroll through the questions until I find one that I'm confident I can answer. Even if I don't know the answer right away, a little research or debugging their problem in my IDE usually gives me enough to help them out. At first it can be hard to do anything on StackOverflow, because of their ranking system. Look for a really easy questions in the beginning and make sure you are the first one answering. Eventually you will be given more freedom to comment, rate others' questions and answers, and do other things like post bounties. Seeing how other people are using technologies and writing code helps me become a better developer as well. I am able to learn from their mistakes or see a bug I had never seen before.

Algorithms

Solving algorithms on LeetCode or HackerRank is like a game to me. It makes development fun and challenging. It allows me to improve my skills in recursion, dynamic programming, and on what data structures to use. It is also a useful skill to have when interviewing for top tier software companies.

More than Code

Not all of my learning revolves around code. Software development is not always about the code we write. As software developers we are building solutions to business problems that our stakeholders have. During my learning, I've improved my knowledge on software architecture, system design, and soft skills.

Software Architecture

Understanding the building blocks of software is a critical part of any software engineer's knowledge base. Not only should we know how to apply the abstract solutions designed by software architects, but we should be able to understand them as well. Even better we should learn what makes a good architecture solution for the given use case. What types of building blocks are available to use? I am no software architect, but I have been paying attention to different software architectures.

System Design

In some interviews, you may be asked a System Design question. For example, how would you build Twitter? What kind of databases would you use? What about load balancers, resilience, caching? One design does not fit all of the problems out there. One must understand why to use a NoSQL datastore as opposed to a SQL datastore. How much uptime do we need? What about the maximum transaction response time? Is a messaging queue appropriate for this system? I'm not going to talk about any of this in detail, but below is a great resource I highly recommend.

Soft Skills

Soft skills are any non-technical skills you bring with you to your profession. These are just as important as technical skills and should be studied just the same. Some people already have these skills strongly developed and others require more focus in these areas. Examples of soft skills include communication, collaboration, the ability to learn, creativity, a healthy ego, accountability, critical thinking, empathy, flexibility, and passion. Not all of these are required, but they go along way in connecting with others and being a great team member. Just as with all technical topics, if you need to improve these skills there are resources out there to help you. After that you must practice, improve, and learn from your mistakes.

Notes & Goals

I know of some people that make a daily log of things they work on for their job and/or on their own time. This is a very effective way to learn and reflect on one's growth. I never did this and don't plan to, but I do have other approaches to this.

Whenever I see an interesting library or framework or I get an idea of a new project to work on, I make a note of it in my phone's Notes app. I recently have transferred that list to a Trello board and I have been working through it.

As for technical notes, I always use Github to store my spikes and technical learnings. That way I can always refer back to them. Writing a blog post is also a great way to make the learning stick and serves as documentation you can visit in the future.

What's better than learning from yourself, right!?

Conclusion

There's many approaches to learning and everyone has their own way. As you can see I take a hybrid approach and always maintain multiple tracks of work. I love learning new things and in the world of software development there's always something new to learn. Don't be overwhelmed by the amount of information there is. Take it step by step and enjoy the journey. Once you find yourself not having fun, stop and try something else or take a break for a while. It will be there when you're ready to come back.