Blindly following coding principles is a bad idea.
“Leave the basecamp cleaner,” “Make the change easy then make the easy change”…
Often, we follow those two principles and start huge refactoring sessions with good intentions but without considering the potential consequences.
Let me share two stories of refactoring sessions that led to unintended consequences and the lesson behind them.
Changing Entities and Value Objects
At a past job, a team member decided to refactor the entire solution before working on his task.
He changed every Domain Entity, Value Object, and database table. What he found wasn’t “scalable” in his experience.
The project was still in its early stage and the rest of the team was waiting for his task.
One week later, we were still discussing about names, folder structure, and the need for that refactoring in the first place.
We all were blocked waiting for him to finish the mess he had created.
Changing Class and Table Names
At another job, our team’s architect decided to work over the weekend.
And the next thing we knew next Monday morning was that almost all class and table names had been changed. The architect decided to rename everything. He simply didn’t like the initial naming conventions. Arrrggg!
We found an email in our inboxes listing the things he had broken along the way.
We spent weeks migrating user data from the old database schema to the new one.
These are two examples of refactoring sessions that went sideways. Nobody asked those guys to change anything in the first place.
Even there was no need or business case for that in the first place.
I have a term for these refactoring sessions: massive unrequested refactoring.
I believe in the “leave the basecamp cleaner than the way you found it” mantra.
But, before embarking on a massive refactoring, let’s ask ourselves if it’s truly necessary and if the team can afford it, not only in terms of money but also time and dependencies.
And if there isn’t a viable alternative, let’s split that massive refactoring into separate, focused, and short Pull Requests that can be reviewed in a single review session without much back and forth.
The best refactorings are the small ones that slowly and incrementally improve the health of the overall project. One step at a time. Not the massive unrequested ones.
Voilà! That’s my take on massive unrequested refactorings. Have you ever done one too? What impact did it have? Did it turn out well? Remember, all code we write should move the project closer to its finish line. Often, massive unrequested refactorings don’t do that.
In my two stories, those refactoring sessions ended up blocking people and creating more work.
These refactorings remind me of the analogy that coding is like living in a house. A massive unrequested refactoring would be like a full home renovation while staying there!
An emergency fund is enough savings to cover our essential expenses for some time. The longer, the better.
That’s the breathing room until you figure out something.
And it’s the difference between being picky about the next job or accepting anything to pay the bills.
3. Always be ready
Let’s always have our CVs updated. Stay in touch with our colleagues and ex-coworkers. Build our professional network.
Let’s always be ready for an interview. Have our data structures and “tell me about yourself” muscles in shape.
Interviewing is broken, I know! But let’s always be ready to leave.
Don’t wait for a layoff to establish an online presence and grow your network. By then, it will be too late.
Voilà! Those are my thoughts about layoffs. I learned that after losing a job, there’s always a positive change. That takes us out of our comfort zone. “Pastures are always greener on the other side,” I guess.
These days I reviewed a pull request in one of my client’s projects and shared a thought about reading database entities and layering. I believe that project took layering to the extreme. These are my thoughts.
For read-only database-access queries, reduce the number of layers in an application to avoid excessive mapping between layers and unneeded artifacts.
Too many layers, I guess
The pull request I reviewed added a couple of API endpoints to power a report-like screen. These two endpoints only returned data given a combination of parameters. Think of showing all movies released on a date range with 4 or 5 stars. It wasn’t exactly that, but let’s use that example to prove a point.
That project had database entities, domain objects, results wrapping DTOs, and responses. To add a new read-only API endpoint, we would need a request object, query, query handler, and repository.
Inside the repository, we would need to map database entities to domain entities and value objects. Inside the query handler, we would need to return a result object containing a collection of DTOs. Another mapping. Inside the API endpoint, we would need to return a response object. Yet another mapping. I guess you see where I’m going.
This is the call chain of methods I found in that project:
Three layers and even more mappings
And these are all the files we would need to add a new API endpoint and its dependencies:
That’s layering to the extreme. All those artifacts and about three mapping methods between layers are waaay too much to only read unprocessed entities from a database. Arrrggg! Too much complexity. We’re only reading data, not loading domain objects to call methods on them.
I believe simple things should be simple to achieve.
For read-only queries, the HODDD book uses two models:
Query Models for the request parameters, and
Read Models for the request responses.
Then, it calls the underlying storage mechanism directly from the API layer. Well, that’s too much for my own taste. But I like the simplicity of the idea.
I prefer to use Query Services. They are query handlers that live in the Infrastructure or Persistence layer, call the underlying storage mechanism, and return a read model we pass directly to the API layer. This way, we only have two layers and no mappings between them. We declutter our project from those extra artifacts!
We put the input and output models in the Application layer since we want the query service in the Infrastructure layer. Although, the HODDD book places the input and output models and data-access code directly in the API layer. Way simpler in any case!
Voilà! That’s my take on read-only queries, layers, and Domain-Driven Design artifacts. I prefer to keep read-only database access simple and use query services to avoid queries, query handlers, repositories, and the mappings between them. What do you think? Do you also find all those layers and artifacts excessive?
Some days ago, I got a message from someone starting his journey to become a Software Engineer. He found my post with the takeaways from the Ultralearning book and asked for feedback.
On the email, my reader explained that he wanted to become a professional Software Engineer with a one-year ultralearning project. Also, he wrote he had a list of resources compiled and already made some progress.
This is my long reply and how I would start an Ultralearning project:
1. Set milestones
Keep yourself focused and motivated with milestones.
For example, after 2 or 3 months of studying, make sure to complete an introductory CS course or have some features of a coding project ready.
Often we underestimate what we can do in a year or get easily distracted.
2. Choose Math subjects wisely
This might be controversial. But don’t get too focused on learning advanced Math.
Depending on the business domain you’re working on as a Software Engineer, you might not need a lot of Math. Unless you’re working on Computer Graphics, Finance, or Simulations.
I’d stick to courses on Linear Algebra and Math for Computer Science.
3. Use roadmaps as inspiration
Find lists of subjects to learn from roadmaps.
If you search on Google or DuckDuckGo or GitHub “programming roadmap <insert year here>,” you will find good resources. But you don’t need to learn all those subjects at once. Instead, understand how a particular subject or tool fits into the larger picture and when you need it.
Only zoom in when you need a particular tool.
4. Write an end-to-end coding project
Write a coding project that reads data from a webpage, calls a backend, persists data into a relational database, and displays it back.
You will learn a lot from this simple exercise:
HTML/CSS,
a UI library,
HTTP/REST,
a backend language,
SQL, and
a database engine.
Quite a lot!
ou will be surprised by how many “real” applications boil down to read and write data from and to a database.
5. Be consistent
I know this is cliche at this point. But…
Set a regular study time and put it in a calendar. I find the green squares on my GitHub profile inspiring to keep myself in the loop.
6. Learn the tech and tools companies are hiring for
Probably, you will hear or read people arguing to “learn X instead of Y” or “X pays more than Y.”
Instead of looking for the best-paying languages, use a more tactical approach, find what companies around you (or on LinkedIn) are looking for, and learn those subjects.
Or, in any case, it seems there’s always a shortage of COBOL developers. I’ve read they’re well paid.
7. Keep a journal
Keep track of what you learn, the resources you use, and the subjects you find challenging.
You don’t need anything fancy. A simple .txt file works. Sorry, if you were expecting Notion. I’m a plain-text lover.
I found this advice about the journal on the book “Never Stop Learning” by Bradley R. Staats.
Voilà! That’s how I would approach a ultralearning project to become a Software Engineer. My last piece of advice is you don’t need to learn everything at once. In the beginning, learn a handful of tools and learn them well. But don’t be afraid of learning something else. Later you could start expanding your toolbox and finding what you like the most.
I wrote my own roadmap for intermediate C# developers. It points to C# resources, but its overall subject structure works for other languages too. This is not for absolute beginners.
I tried to challenge myself with mini ultralearning projects. I choose to learn enough React and Go in 30 days.
Some days ago I found out this Hacker News question about what blogging has done for blog writers. I realized that I published my first blog post five years ago. I’d like to share what blogging has done for me.
In a past post, I shared how I started blogging and the story behind my first post. Long story short: I didn’t want to throw away some hours of Googling.
1. What has my blog done for me?
I wish I could tell that I could live out of my blog. That’s not the case yet. But it had opened doors here and there.
After sharing some of my posts on my LinkedIn profile, I got an invitation to create text-based programming courses on a new teaching platform. I wrote a couple of C# courses there.
Again from LinkedIn, someone from the Marketing team of a software company reached out to me for a content collaboration. I wrote two sponsor posts here on my blog and others on its company blog.
On another occasion, an acquaintance set me up for an interview for a full-time opportunity as a software engineer. I declined it, but that interview ended up being another content collaboration. I helped that company to start a Medium publication.
Apart from content collaborations, keeping a blog made learn two skills: online writing and SEO.
I haven’t updated my first post. It’s right there to remind me how I started. At the time, I had zero experience writing online. I only threw some words into an empty file and put it online.
I had to learn to use shorter sentences, descriptive subheadings, and clear structure.
I learned to target my posts to a user search query. Also I learned to distinguish between posts I want to rank and posts where I share some thoughts. This is one of them.
I stopped writing about whatever came to my mind to follow a topic over a series of posts regularly.
3. Sources of inspiration
In all these years, I have received inspiration from others in the process.
The book Show Your Work by Austin Kleon inspired me to keep writing. Not only do the end results matter, the process to get there, too. I learned that from the book.
I follow the mantra: “If something takes you more than 20 minutes to figure out, it should be a post.” I learned that from a YouTube video, I can’t find any more.
4. Some of my favorite and popular posts
In these five years, I’ve written 152 posts, to be precise. Some blog posts came from my frustrations, curiosity, and learning. Often, I like to think of my blog as my own time capsule and a tool to preserve my keystrokes.
Parsinator: A tale of a PDF parser: This is about Parsinator, a small project I wrote in record time to keep one of my previous employers onboarding new clients.
A quick guide to LINQ with examples: I wrote this one to help a friend. She was preparing for a technical interview. This is an “all you need to know” post. I ended up expanding it into a full series of posts and a text-based course.
Unit Testing 101: This is one of the guest posts I originally wrote on exceptionnotfound.net. I expanded it to a whole series of posts about unit testing.
