DEV Community: Alessandro Aiezza

Favorite Git Things

Alessandro Aiezza — Thu, 16 Oct 2025 19:40:18 +0000

My Favorite Git Tools and Tutorials

Tools

Eclipse Git Plugin – https://projects.eclipse.org/projects/technology.egit

I know, it's Eclipse… Please don't judge me. But as far as feature‑rich git GUI goes (say that ten times fast), this one just wins IMHO.
The Infamous "Git Cheatsheet" – https://ndpsoftware.com/git-cheatsheet.html

Tutorials

Knowledge is Power: Getting out of trouble by understanding Git by Steve Smith – https://youtu.be/sevc6668cQ0?si=h4zXfaFIejBE-9l_
Advanced Git Tutorial – https://youtu.be/0SJCYPsef54?si=-V9kCLP68scDjncj (very low level, but highly informative)

But why care about SOLID?

Alessandro Aiezza — Fri, 09 May 2025 16:52:09 +0000

Or: Why care about any Software Engineering principles?

Embracing principles makes you a more adaptable engineer. You’re no longer tied to a specific framework, language, or tech stack. Instead, you can work effectively with the tools at hand and make them work for you.

For example, I appreciate the SOLID principles. When I have the freedom to choose, and it fits the project, I often reach for Kotlin. It makes applying core principles straightforward in most cases.

SOLID Principles in Kotlin

// Single Responsibility Principle
class ReportGenerator {
    fun generate() { /* ... */ }
}
class ReportPrinter {
    fun print(report: ReportGenerator) { /* ... */ }
}

// Open/Closed Principle
open class Shape { open fun area(): Double = 0.0 }
class Circle(val radius: Double) : Shape() {
    override fun area() = Math.PI * radius * radius
}

// Liskov Substitution Principle
open class Bird { open fun fly() = "Flying" }
class Sparrow : Bird()
class Ostrich : Bird() { override fun fly() = throw UnsupportedOperationException() }

// Interface Segregation Principle
interface Printer { fun print() }
interface Scanner { fun scan() }
class MultiFunctionPrinter : Printer, Scanner { /* ... */ }

// Dependency Inversion Principle
interface Engine { fun start() }
class Car(private val engine: Engine) { fun drive() = engine.start() }

But what if I need to use something else, like Go? The specific language isn’t the most important thing. As long as the problem is solvable with the available tools, what matters is that they support the principles that guide your work.

I care about the mission and delivering value, not unnecessary complexity or academic perfection. My goal is to leave codebases better than I found them—clear, maintainable, and kind to those who come after me. That’s our responsibility as software engineers.

Software engineering principles and design patterns popularized by leaders in our industry exist for a reason. They’ve done the hard work and generously shared their insights. Why not stand on the shoulders of giants?

Some giants to thank:

Gang of Four (Design Patterns book)
Martin Fowler
Eric Evans (Domain-Driven Design)
Robert C. Martin (Uncle Bob) (SOLID)

Here are those same SOLID principles, but in Go—this time, using functional types where it makes sense:

// Single Responsibility Principle
type ReportGenerator func() string
type ReportPrinter func(report string)

func generateReport() string { return "report" }
func printReport(report string) { /* ... */ }

// Open/Closed Principle
type Shape interface { Area() float64 }
type Circle struct { Radius float64 }
func (c Circle) Area() float64 { return math.Pi * c.Radius * c.Radius }

// Liskov Substitution Principle
type Bird interface { Fly() string }
type Sparrow struct{}
func (s Sparrow) Fly() string { return "Flying" }
type Ostrich struct{}
func (o Ostrich) Fly() string { panic("can't fly") }

// Interface Segregation Principle
type Printer interface { Print() }
type Scanner interface { Scan() }
type MultiFunctionPrinter struct{}
func (m MultiFunctionPrinter) Print() { /* ... */ }
func (m MultiFunctionPrinter) Scan() { /* ... */ }

// Dependency Inversion Principle
type Engine func() error
type Car struct { engine Engine }
func (c Car) Drive() error { return c.engine() }

At first glance, the code looks different. Naturally—it’s a different language with its own syntax and idioms. But the underlying principles remain the same, unlocking the same benefits in your codebase. That’s why it’s always worthwhile to learn the features of the language you’re working in.

My guiding steps:

Make it work
Make it right
Make it better

I encourage you: Find ideals and principles that you and your team can support. Then, be open to what that might mean for your code. It may involve using language features that are unfamiliar at first.

But if it leaves your codebase easier to maintain, more readable, better tested, more modular, or more aligned with the ubiquitous language of your domain—embrace it! You’ll be improving yourself, your team, and your product.

And if you care about the people for whom you're building, that should be motivation enough.

Thanks for reading! ✌️

The Uncoding: Elevating the Craft of Software Engineering

Alessandro Aiezza — Sat, 23 Nov 2024 18:36:23 +0000

Introduction

At one point in my career, I had the privilege of working with a brilliant colleague who introduced me to a concept he called “uncoding.” The name immediately grabbed my attention, as I’m sure it might for anyone who has wrestled with unclear or overly complex code. The presentation he gave was fascinating, and it began with the provocative observation that the word “code” itself suggests something obfuscated.

The very term we use to describe our work as software engineers implies secrecy, complexity, and difficulty—qualities fundamentally at odds with our purpose: to solve problems and communicate solutions effectively. With this in mind, the concept of "uncoding" invites us to rethink how we write, structure, and even talk about our work.

How Did We Get Here?

The origins of obfuscated code may have innocent beginnings. Historically, the first computers were enigmatic machines accessible only to a small group of highly educated pioneers. Figures like Ada Lovelace, Alan Turing, Grace Hopper, and John von Neumann laid the groundwork for what we now call computing. These trailblazers and the like, worked at the intersection of mathematics, engineering, and philosophy, often crafting code directly in binary, assembly, or even punch cards—a far cry from today’s expressive high-level programming languages.

To program a machine in those early days required not only mastery of the software but also an intimate understanding of the hardware it controlled. Each instruction was carefully crafted to manipulate physical components like transistors and vacuum tubes. Contrast this with today: modern engineers can build complex systems without a deep understanding of hardware, thanks to abstractions like operating systems, libraries, and APIs.

While this abstraction has undoubtedly accelerated innovation, it has also dulled our reverence for the underlying marvels of technology. Few pause to consider that their sleek devices rely on microscopic transistors, spaced nanometers apart, functioning at such precision that a single particle of dust could destroy their operation. Software engineers now wield unprecedented power to create, yet many of us remain shackled by antiquated habits of obfuscation.

Shameless plug for one of my favorite books that inspired my awe for our modern day technologies

Why Is Code Still Hard to Read?

If technology has advanced so far, why do we continue to produce codebases that are difficult to decipher?

Legacy Practices: Early programming languages like Assembly and C required succinct, dense expressions due to hardware constraints. While modern languages afford us the luxury of readability, many still cling to practices born of necessity in an earlier era.
Pride and Job Security: Some engineers write complex, unintuitive code to showcase their cleverness or to secure their roles. The thinking goes: "If only I can understand this, they’ll always need me."
Apathy and Time Pressure: Deadlines often push us to prioritize functionality over clarity. Writing readable code takes time—time that managers may perceive as wasted when the code "already works."
Inexperience: Junior developers may simply lack the knowledge or guidance to write clean, maintainable code.

While these reasons are understandable, they ultimately harm both the engineers maintaining the code and the businesses relying on it. Poorly written code is like a debt that compounds over time, leading to inefficiencies, bugs, and burnout.

The Philosophy of Uncoding

"The Uncoding" is about shifting our perspective on what it means to be a software engineer. It’s not just about making something work; it’s about making it work well, making it maintainable, and making it enjoyable for others to build upon.

This principle aligns with a simple mantra I hold dear:

Make it work.
Make it right.
Make it better.

What Does "Right" Look Like?

To embrace "uncoding," we must understand what clear, maintainable, and effective code looks like. Here are some key traits:

Readability: Code should be easy for another engineer to understand at a glance. This includes intuitive naming conventions, clean formatting, and clear comments where needed.
Maintainability: Code should be structured in a way that allows it to be updated, extended, or refactored with minimal effort.
Simplicity: Avoid unnecessary complexity. The simplest solution that works is often the best.
Testability: Code should be easy to test, both manually and automatically, to ensure reliability and reduce the risk of future bugs.
Alignment with Domain Concepts: Code should model the domain it serves, using terminology and abstractions that align with the real-world problems it addresses.

These principles may seem obvious, but in the fast-paced world of software development, they are often sacrificed. "Uncoding" is about making these traits a priority, no matter the circumstances.

Putting "Uncoding" into Practice

If you’ve made it this far, you’re likely convinced that "uncoding" is worth considering. But turning this concept into part of your daily work is the real challenge.

"Uncoding" isn’t about perfection; it’s about consistent improvement. It’s about treating code as a way to communicate clearly and build solutions that stand the test of time. Small, intentional steps can make a big difference over time.

Where to Begin

Start Where You Are: Identify one part of your codebase that could be clearer. Whether it’s renaming variables, adding comments, or simplifying a function, take the first step today.
Get Your Team Involved: Share this article or discuss the concept with your peers. The more aligned your team is, the easier it becomes to adopt these principles.
Commit to Iteration: Change doesn’t require sweeping refactors. Instead, focus on improving clarity with each new feature or bug fix, and let progress build gradually.

The Tangible Benefits of "Uncoding"

For tech leaders, the principles of "uncoding" aren’t just about improving the codebase—they’re about delivering measurable value to your organization. While some might see clean, readable code as a "nice-to-have," its benefits are far-reaching:

1. Cost Savings

Clear code reduces time spent deciphering complex logic, debugging, or rewriting poorly understood sections. Over time, this means fewer hours lost to inefficiency and fewer costly mistakes caused by misunderstanding how a system works.

2. Risk Reduction

A well-documented, readable codebase minimizes the risks associated with employee turnover. When knowledge isn’t tied to a single person, teams can adapt more easily when members leave or change roles.

3. Faster Onboarding

New engineers can contribute more quickly when the codebase "speaks for itself." Instead of relying solely on tribal knowledge, clear naming, comments, and modular design help new hires hit the ground running.

4. Improved Employee Retention

Engineers who work in a well-structured codebase are less likely to feel frustrated or burned out. "Uncoding" principles foster an environment where developers can focus on solving interesting problems instead of untangling confusing legacy systems.

5. Long-Term Scalability

As your product evolves, a clean and well-organized codebase makes it easier to add new features without introducing significant technical debt. This scalability supports sustainable growth for your business.

Armed with the right language and metrics, we can demonstrate that "uncoding" is not a luxury but a necessity for any team serious about quality and longevity.

Inspiring Your Team to "Uncode"

If you're a tech leader or team lead, you hold the key to fostering a culture of "uncoding" within your team. Encouraging engineers to embrace clarity and intentionality in their work doesn’t just benefit the codebase—it boosts morale, collaboration, and overall productivity.

Strategies for Leaders

Lead by Example

Model the behavior you want to see. In your code reviews and contributions, prioritize readability and maintainability. Show your team that clarity isn’t optional—it’s a core value.
Make It a Team Priority

Integrate "uncoding" principles into team workflows. Set guidelines for naming conventions, documentation, and clear architecture. Incorporate these into your onboarding processes so new hires understand their importance from day one.
Provide Time and Space

Encourage your team to refactor when needed, and allocate time for knowledge-sharing sessions on these principles. Ensure they feel supported, not rushed, when balancing deadlines with quality.
Highlight Wins

Celebrate when team members produce work that embodies "uncoding." Share examples of how clearer code saved time, avoided bugs, or improved onboarding for new engineers.

The Future of Uncoding

The industry is already moving toward tools and techniques that align with the philosophy of uncoding. Domain-Driven Design (DDD), automated documentation, and AI-assisted coding tools like GitHub Copilot and ChatGPT exemplify this trend. In fact, with natural language processing and machine learning, we’re inching closer to a future where we describe problems in plain English and receive functional, optimized code in return, but at enterprise scale!
But until that day arrives, we have a responsibility to hone our craft. We may never write code as elegant as a novel by C.S. Lewis, but we can strive for clarity, intention, and artistry in what we produce.

Conclusion

Let us leave a legacy of clarity, craftsmanship, and respect for those who follow in our footsteps. Let our code be a joy to read, a tool for collaboration, and a foundation for innovation.
In the following articles, I’ll delve deeper into practical techniques for uncoding, from leveraging language features to applying design principles like SOLID and DRY. Together, we can build a future where our "code" is not just functional but inspirational—where our craft as software engineers transcends the technical to become a true art form.

May we uncode our work, one instruction at a time.

Idempotent

Alessandro Aiezza — Wed, 22 Feb 2023 19:09:44 +0000

idempotent

Of all the places to FINALLY understand OAuth

Alessandro Aiezza — Wed, 22 Feb 2023 17:29:59 +0000

Kroger has developer guides, and I read their documentation on OAuth2, and it is honestly some of the best documentation I've read on the subject.

Go check it out: https://developer.kroger.com/documentation/public/security/guides-oauth

✌️

The Coding Language you Write Affects your Personality

Alessandro Aiezza — Fri, 11 Nov 2022 16:10:03 +0000

I just found out about ~~my personality disorder~~ a personality–related phenomenon.

On the road to learning Italian, it has always fascinated me that my personality does appear to change slightly when I'm speaking it. The change is subtle, but enough that I've started to notice the difference when talking with native speakers.
Here is an article to back up the credibility of this phenomenon: https://www.psychologytoday.com/intl/blog/life-bilingual/201111/change-language-change-personality

As I have been learning Swift for iOS and Kotlin for Android and backend services, I am starting to notice the same type of shift in the way I code. My "engineering personality" and my behaviors seem to change.

One example is I think I prioritize more of a "get'r'done" personality in Swift than I used to in Java. In Java, I tend to think much more about Test Driven Development.
Maybe because unit testing in Swift did not come as easily to me as it did in the JVM.

Another example is when I'm in Kotlin I am much more interested in wrapping even the simplest of my domain objects in a data class. No primitive data types are left unwrapped. An Integer has a purpose and a name, and I create a data class for it. In Java, I would do this too, but it was much more daunting and sometimes I would not take the time.
I wonder if that's because data classes are so much easier to write in Kotlin.

🇮🇹 In Italian, I feel so much more chill and well spoken. There are no phrasal verbs and there are no trailing prepositions allowed, so much speech feels so much more stable.

🇺🇸 In English, because it is my native language, I throw words around like a madman, sometimes trying to seem impressive and hoping that my sentence will end correctly.

🇮🇹 In Italian I need to think ahead of time and sometimes put my pronouns at the front of my sentence as opposed to at the end.

I'm wondering if any software polyglots have encountered this same phenomenon.

My Italian Journey - Italian learning resources

Alessandro Aiezza — Wed, 14 Sep 2022 15:12:38 +0000

This is probably not the place for it, but it is a convenient place to put it.

I have been learning Italian since April 2018 and the following resources have been extremely helpful. Enjoy.

Quali risorse usi per imparare l'italiano?

Youtube

My favorites:

Learn Italian with Lucrezia Oddone An Italian who is fluent in English but teaches Italian in Italian (Immersive learning). She also provides the Italian captions for her videos! (Watch the comprehensible input video to learn why that is important). This has been a great channel for me to play in the car at 0.75 playback speed and use a technique called "shadowing"; I just repeat everything she says, as she says it.
Italy Made Easy (with Manu) An Italian‑born who teaches in English
QVC Italia This one sounds funny to people when I recommend it. It was actually recommended to me by Manu! Passive listening is an integral part of language learning. It keeps your mind familiar with the sounds and feel and cadence of your target language. The best part about QVC Italia is that they are always streaming live, so the content is fresh and I can keep it on in the background while I'm working. Another great part of the content on this channel, is that they are always talking about a product, something tangible. So complex and abstract ideas is not normally discussed on the channel. It makes it easy to learn new nouns and the adjectives often used to describe them. (You may even find a cool Italian product you want to buy 😆)
Easy Italian This channel essentially nails it when it comes to subtitles. they are easy to read and in both English and Italian! Studies show that comprehension of your target language of video content goes down when you simply read subtitles in English, and it goes up when the subtitles are in Italian, and it goes way up when both languages are present in the subtitles. Also, great content! They interview real people in Italy all the time. Very fun.
Tom Txxytu An American who teaches in English and Italian
Rock 'N Learn If it sounds corny, that is because it is. This channel is meant for children, but when you are a child yourself in the language you are learning, what better way to learn the basics than how children learn best.
More channels: https://www.mosalingua.com/en/youtube-channels-to-learn-italian/, https://www.alllanguageresources.com/italian-youtube-channels/

Apps

Google Translate This one is a must! For the most part, it is spot‑on in translating for you.
Reverso Translate and Learn (aka Reverso Context) Where Google Translate fails (particularly around idioms) this app cleans up! It references real articles and other literature written and translated by native speakers so you know it is more accurate. Still be careful about the context you use what you learn here.
HelloTalk This would be a great one for all of us to join since there is an excellent correction mechanism in the app! By now, I have made lifelong friends through this app.
Duolingo DuoLingo has helped me expand my vocabulary a lot! And there is a streak mechanism that keeps me focused.
Memrise Not my favorite app to be honest, but they leverage many of the same psychological hacks that Rosetta Stone does by including 2‑second videos of real Italians speaking the language.
LinguaLoops Short‑term memory commits to long‑term memory with 1) repetition 2) sleep and 3) high emotional contrast accompanying the new information. LinguaLoops focuses on repetition in the form of cute, catchy‑tunes for the verb tenses.

Podcasts

Radio 24 My favorite is Effetto Giorno, an Italian radio news show. Just keep in mind, this is a real Italian radio show for Italians. It is fast, idiomatic, and uses very unique language since they discuss economics, politics, geography, and other social topics.
Let's Speak Italian I think this one is excellent for the beginner. A perfect car ride podcast for expanding your vocabulary.
SBS Italiano Another advanced one, but they include news from Australia which is cool as well as interviews and random community stories. There are news stories, but they are more interesting ones.

Netflix

Tips

When using Netflix for language learning, this Chrome Plugin is a MUST!
Change your Netflix localization to Italian! (https://help.netflix.com/en/node/13245) What's nice about this one, is that it only affects your profile, not the whole account! So you can even make yourself an extra account in Netflix for your Italian shows, and keep your regular one.

Shows

I'll list some of the kid shows here, but some of the other Italian shows that I do enjoy, can also be really graphic. So I'll let you just search for "Italian" and discern what is appropriate for you or not 🙂
The ones I list here though are clean and I can vouch for!

Pocoyo It is just cute
Parole In Festa My kids and I watch this all the time! The songs are super catchy and give you good Italian baby language to use around kids!
La Suburra Not kid friendly, but I seriously love the acting, the characters, and the story.

Books

La Ragazza nella Nebbia by Donato Carrisi [Fiction]
Quei 10 giorni oltre la vita by Mauro Prosperi [Nonfiction] I purchased my physical copy here
More books recommended by Lucrezia: https://www.youtube.com/watch?v=E-1T09Y2s0U&ab_channel=LearnItalianwithLucrezia, https://www.youtube.com/watch?v=rVSy2TomGFg&ab_channel=LearnItalianwithLucrezia, https://www.youtube.com/watch?v=vBYYj-9Qhzs&ab_channel=LearnItalianwithLucrezia, https://www.youtube.com/watch?v=9LDI0j_p5HM&ab_channel=LearnItalianwithLucrezia

Children's Books

These are all a big favorite with my kids.

A series of Bilingual books by Shelley Admont https://www.amazon.com/stores/author/B00CZJ2UTI/search?terms=Italian
Several titles by Gabriele Clima with one of my all time favorites being La Popò, come la fo?
The Italian Experiment offers a unique variety of stories for free that can be read online along side the English translation! Some of the stories are even animated and available on YouTube.
- The favorite among my kids at the moment is Il Polletto Carlleto. The YouTube video is available here hosted by the Fable Cottage.

Other Ideas

Change your Netflix localization to Italian! (https://help.netflix.com/en/node/13245) What's nice about this one, is that it only affects your profile, not the whole account! So you can even make yourself an extra account in Netflix for your Italian shows, and keep your regular one.
If you feel really daring, you can do this to your phone too!

I hope this helps someone. Happy Italian learning!

Somebody has been coding in MY repo!

Alessandro Aiezza — Fri, 05 Nov 2021 21:04:48 +0000

You want me to approve what?!

You are improving as a Software Engineer. If that is true, then you're at your pinnacle of knowledge right at this moment. Everything you've done in your career and life have led up to this exact second. All that experience, all the mistakes you have learned from, all the successful applications you stood up! And they're still in production to this day, gosh darn it!

So why in the world would anyone want to do a thing like go into your code base and submit a Pull Request for a new feature in a completely different way than you would have ever done? No newline characters at the end of source code files, its filled with pineapples, using tabs instead of spaces?!

I mean, it's obviously wrong. Right?

Those poor bears

The story of Goldilocks and the three bears.
If you are not familiar, I suppose it is a rather entertaining read. A young, innocent, blond-haired lass strolls into the empty cottage belonging to a family of three bears. Said bears are out on a stroll of their own; You see, they have made porridge for themselves, and want to give it time to cool off.
Well Goldilocks, rather selfishly, takes it upon herself to contaminate food she dislikes, devour that which she does like, ruin furniture, and pass TF out in one of the beds of these three, wonderful bears.
They return home to the mess, discover the unintending thief, and frighten her into fleeing for her life.

The moral of this children's tale is the need to respect the privacy and property of others and how your actions hurt others.

That's exactly what's happening to me!

You, the diligent, experienced programmer have been asked to "take a stroll in the woods". That is, your skills have been requested on another project in the company.
The code you have written is a lean, mean, revenue generating machine; But like most code, it will need maintenance, perhaps even additional features. And who better to do that than another developer with practically no experience in the domain space or practice in the design patterns you have so elegantly employed in said project.

The dreaded, yet well-meaning, Goldilocks has been granted authorship to your code.

And now, there is a pull request. Of course you have alerting set up for such a thing. So you see it immediately. Unlike the three bears, you are not going to simply walk away from your shelter without a home security system only to allow silly children to ruin what you have worked tirelessly to build.

But perhaps you also don't want to be seen as an angry, ferocious bear either… After all, this is an adorable, innocent child. You are upset, but can't destroy the pull request author, but you also need to show them who's boss over this code!

So you start with small comments about what's wrong. Perhaps this turns into a heated debate over PR comments and you start duking it out. Or perhaps the other party "didn't know better!" and immediately crumples to your demands, changing every bit of code you despise for "not being best practice". Maybe even merging that branch you created off of their branch that "corrects" the terrible practice and nonsense they almost introduced into your code.

If the developer puts up a fight though, the code may never get merged because it needs your blessing and approval. And now that person is dealing with questions from their leader of "why is this work taking so long?". Now the finger is pointed at you!

But you were only protecting your house! Look at the mess Goldilocks almost made!

You decide your talents are best appreciated elsewhere, and say goodbye. After all, you're a senior engineer. Recruiters be slidin' into your LinkedIn DMs constantly!

✌️

Goldilocks Syndrome

If you have been blindly agreeing with everything I've said so far, you had better not be a senior engineer at your company.
And this is for you:

🚩

This is setting the stage for a pretty toxic work environment; That of the ferocious over-bearing developer controlling every move being made on his/her codebase.

This is Goldilocks Syndrome. And it occurs in very specific scenarios in an engineer's career. Avoiding this syndrome though, is a hallmark of a great engineer, and should eventually become an expected trait of any engineer; Especially a senior engineer.
To be presented with this predicament in the first place is an indicator that you are probably, objectively a good developer. Now at this stage, you can prove that you are also a good teammate.

What you do next in this situation, will either be remembered as a beautiful milestone in your career, or an awful trauma for the other party combined with a stab to your own personal brand.

When the opportunity arises that an "external" is requesting her own changes be merged into your codebase, what should you really do?

Going from "the bear", to "the balanced mentor"

OK, the metaphor does not work perfectly here. Goldilocks was genuinely in the wrong in that story, and needed to learn a lesson. In her case, I can only imagine it was traumatic, but she messed up their house and ate their dinner!

However, the lesson you have the opportunity to facilitate here, does not need to be so painful.

Also, don't assume you got it perfect in the first place! We all have room to improve and teach others along the way.

In this case, it's more likely you will end up teaching someone that's dealing with "imposter syndrome", not someone who is actively seeking to dramatically deviate from the codebase standards.

Real-life example

Scenario: New PR submitted to your code base by a developer that has taken ownership of it, as you have moved on to another project. Not much needs to change, just the occasional new feature, new button, new endpoint, you name it. The new dev simply needs to maintain it! You did a great job (hopefully), but you're needed elsewhere.
The dev needs to make a change, and wants your input knowing you as the domain expert, or at least needs your approval in order to merge the code.

We have already outlined a poor response to this situation.
Yet, another terrible response to this is to simply approve the request!
You might be tempted to do such a thing though, and with all the best intention, if you don't want to hold up their work. And you also have your own work to do, so you can't spend forever on this one measly pull request.
How can you give this developer just enough to set them on the right path?

The Goal: The new feature makes it in with as little, to no new tech debt as possible.

Much easier said than done, so let me leave you with a few tips that I have learned, that can help set up you and the other team for success.

Tips for finding that balance

🟢 Be curious, not accusatory

Asking "why would you do it this way when we do it this way over in this other function?" is aggressive. It will never have the outcome you want. It will lead to the other person feeling the need to be defensive, or worse, will crush their spirit into doing it exactly the way you tell them.

This developer will not grow in that environment. And believe it or not, you actually should want them to. If they do grow, and even better, if you get to see that growth occur, you develop trust with them. Maybe even getting them to a point, that they shouldn't even need your input anymore! They can be trusted by all to simply - own the code.

Exchange "why" with "what"

Instead, you could say, "This is an interesting approach. What made you do it this way?". This is far less abrasive to the other party. You are engaging in a dialogue now, not an accusation. Internally, you know you would not have coded it that way. And your questions demonstrate your open-mindedness to the new technique instead of shutting it down. You are curious, and interested in learning about their approach.

More often than not, what I find these types of questions tend to do is bring up more conversation around the heart of what is trying to be accomplished.

Which brings us to the next tip.

🟢 Ask what they are trying to do

This one might seem obvious, but it is far from human instinct in my experience. What is trying to be done may also be really well-defined if the changes are rather straightforward, or the developer is really good at documenting. Still, attempt to simply reiterate what is trying to be done in your own words to the developer, and allow her to respond. What you're looking for here is: "That's right".

This grows the mutual "pool of understanding". One of the worst things you could do is delve deeply into a rabbit hole of conversation about a specific line of code, but you have yet to be on the same page as to what the overall goal that the whole pull request hopes to accomplish.

If you do not get the "That's right" response. This next tip will help.

🟢 Listen

Stop waiting for other people to be finished talking, so that you can say what you want. I am super guilty of this, and I still need to stop.

Really listen to the other person. She will probably explain what she is trying to do; Or what she was hoping to accomplish through some specific piece of code that was written.

Only after you listen well, and not simply have "the answer" ready in your cannon, can you start to balance what you allow in to the codebase, and what you wish to keep out at all costs.

🟢 Choose your battles wisely (Look for the reddest of red flags 🚩)

A quote by C. JoyBell C. (according to the internet). But it couldn't be more important advice.

Especially after you have cultivated a decent level of trust with the other developer, you can and should enter into healthy conflict over something in the pull request where you deem it necessary.

Look for those spots of code that really violate best practices, or violate the standards of the specific language in which the project is coded. And believe me, if you're as good as you should be for having been an owner of this codebase in the first place, you will know it when you see it.

Then, kindly explain something you are seeing, and again, ask what made them code it this way. After listening, if you still think it's a bad call, suggest the alternative.

Examples:
- 8 nested for-loops
- Side Effects in functions
- one letter variables
- stuff that is intrusively and selfishly inconsistent with how the codebase is already doing it: introducing spaces when tabs are what are used for whitespace. When in Rome, code as the Romans (This one is the equivalent of "wiping your feet" before entering a stranger's home who has invited you in)
- deserializing JSON in a unit test to set up an object instead of calling new to construct the thing 😊

🟢 Choose to let in the code that will "work" but isn't perfect (by your definition)

This is a tough one. It is the last, and most important tip.

When you say, "Yes" to a piece of code, that (A) you don't agree with but (B) you know will work, you have made a big step towards becoming a better human being, let alone a better engineer.

This, less-severe, piece of tech debt, that may even fall off of your secret, internal list of things you have to fix someday, and that's OK, is setting up for a great win in the future.

The code works, and you didn't need to correct anything. Congrats! You just shipped code and improved your product which is great for your users! And it all happened that much faster because we didn't need to spend time talking about this one thing.
By doing this, you allow the learning to take place down the road for that developer. Let them realize it was a mistake, if it was a mistake. Then, they only get valuable experience in refactoring practices and you don't get all the credit for finding it sooner, only making your fat head even bigger than it already is 😉.

A good teacher is like a candle – it consumes itself to light the way for others
At last, the most interesting side effect to this act, a piece of what was shipped, may actually have been a really great freaking idea! A new design pattern maybe. One that you never even would have thought of… Woah!
Correct me if I'm wrong, but I'm pretty sure companies enjoy bragging about all the "innovation" they be doing. Congrats. You now just allowed it to happen.

Finally, its over

I hope this was helpful to someone. This list may not be perfect, or complete, but these practices continue to help me in my career, and even other areas of my life!

I don't do any of this perfectly yet, maybe I never will. But day by day, these traits have started to come more naturally to me, and frankly, they feel much better to operate in. It's surprising almost the amount of anxiety and frustration these tips have the power to alleviate.

A growth mindset and flexible thinking is about trying and learning from feedback. Know your values and don't compromise them. At the same time, be accommodating to different ways that meet those values and get it done.

If you end up working with me someday, and find I am treating you like Goldilocks, please call animal control.

I would rather care about my teammates, more than "my" codebases (Which are, in most cases, not even my codebases to begin with. The company you work for owns everything you produce while on-the-clock. 😆).

If you made it this far, thanks for reading all this.

Here's a cheers to becoming better 🍻

Are you seriously not using Java 15 yet?

Alessandro Aiezza — Wed, 10 Feb 2021 18:08:20 +0000

Introduction

What I want to accomplish: I want to move to Amazon Corretto 15 so I can use the new features in my work projects. These features feel long awaited; So much so, Kotlin and Lombok continue to gain popularity.
How: I plan to convert an existing Java project from amazon‑corretto‑11 to amazon‑corretto‑15, and add code to the project which will leverage the new features just to see how our infrastructure handles them.
Caveats: This particular service is dockerized. So we would also need to update our docker image to use Java 15. I plan to run the project outside of docker just using mvn from a local shell.

Conversion process

Change the Maven compiler plugin version.

In the build section of the pom.xml file:

    <build>
        <plugins>
            . . .
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <release>15</release>
                    <compilerArgs>
                        <arg>--enable-preview</arg>
                    </compilerArgs>
                </configuration>
            </plugin>
            . . .
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <configuration>
                    <forkCount>0</forkCount>
                    <argLine>--enable-preview</argLine>
                </configuration>
            </plugin>
            . . .
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-failsafe-plugin</artifactId>
                <configuration>
                    <argLine>--enable-preview</argLine>
                </configuration>
            </plugin>
        </plugins>
    <build>

I needed forkCount in the surefire plugin configuration because the parent pom declares something higher than 0, SUREFIRE-1528.

This is a great reminder that some of the features in 15 are technically experimental still and require preview.
While I would be hesitant to use preview features in a production system, Amazon has faithfully iterated on corretto-11 through patches. Thus, as issues arise, there is iteration to fix those problems, and I believe that would also extend to preview features.
And I think it's safe to assume that corretto-15 will also have patches issued.

Installing Amazon Corretto 15

Download amazon-corretto-15

Or for the Linux users, you couldn't ask for a sweeter time: Linux package managed installation instructions

Updating my IDE

IntelliJ

Download the latest IntelliJ and you will have been all set to use Java 15 since version 2020.2!

Eclipse

Download the latest Eclipse

Using the JDK

Just make sure when you're setting up your IDE, that you point to the correctto JDK installation!

Let's try out these Java 15 features

No more need for lombok here | Records

Here is a simple class in the existing project. Users in this domain are given a "baby step" between 0 and 7.

With Lombok:

@lombok.Data
public class UserBabyStep {
  public static final UserBabyStep NO_BABY_STEP = new UserBabyStep();

  public static final int DEFAULT_BABY_STEP = 0;
  public static final int MAX_BABY_STEP = 7;

  private final int value;

  public UserBabyStep() {
    this.value = DEFAULT_BABY_STEP;
  }

  public UserBabyStep(final int value) {
    if (value < 0 || value > MAX_BABY_STEP)
      throw new IllegalArgumentException(
          "The Baby Step of a user must be between 0 and 7 inclusively.");
    this.value = value;
  }
}

Hello records!

public record UserBabyStep(int value) {
  public static final UserBabyStep NO_BABY_STEP = new UserBabyStep();

  public static final int DEFAULT_BABY_STEP = 0;
  public static final int MAX_BABY_STEP = 7;

  public UserBabyStep() {
    this(DEFAULT_BABY_STEP);
  }

  public UserBabyStep(final int value) {
    if (value < 0 || value > MAX_BABY_STEP)
      throw new IllegalArgumentException(
          "The Baby Step of a user must be between 0 and 7 inclusively.");
    this.value = value;
  }
}

Notes for `record`

Lombok will generate a more Java‑canonical getter method for fields: getValue(). The getter method produced by the record feature is: value().
This is more similar to how the Immutables library operates, and is a fancy way to get around when you may, or may not want isFlag for boolean getters. Especially if you are like me, and prefer leveraging the type system for wrapping primitives in a more domain‑driven class.

Another note is that record‑declared classes cannot extend another class! Only implement interfaces.

Necessary usage of the canonical constructor

Finally, when using records, all constructors must call the canonical constructor. That is, the constructor with the same types, order, and number of arguments that are declared on the record itself.

Who's up for Checkers?

Instead of just looking for more things to change around in this existing project, I'm going to add irrelevant code simply for the sake of flexing the new features. And then, I want to see how it compiles and how the project plugins handle it.

Also, I isolated the checkers code if you'd like to take a closer look.

Sealed Interfaces

I'm going to mess around with this here, however, see the note at the end of the article concerning sealed interfaces.

A checker board tends to have two alternating colors tiling a 8 x 8 board.

Each space/tile can have contents; a red or black token.

To demonstrate the difference between individual tiles, there is a sealed interface called Space which permits a BlackSpace and a RedSpace. Each subclass then also implements the wither method that allows a space to take new contents.

public enum Contents {
  EMPTY, BLACK, RED;
}

public static sealed interface Space permits BlackSpace, RedSpace {
  public Contents contents();
  public int x();
  public int y();
  public Space withContents(final Contents state);

  public default boolean isEmpty() {
    return contents() == Contents.EMPTY;
  }

  public default boolean contains(final Contents state) {
    return contents() == state;
  }

  public record BlackSpace(Contents contents, int x, int y) implements Space {
    public BlackSpace(final int x, final int y) {
      this(Contents.EMPTY, x, y);
    }

    @Override
    public Space withContents(final Contents contents) {
      return new BlackSpace(contents, x, y);
    }
  }

  public record RedSpace(Contents contents, int x, int y) implements Space {
    public RedSpace(final int x, final int y) {
      this(Contents.EMPTY, x, y);
    }

    @Override
    public Space withContents(final Contents contents) {
      return new RedSpace(contents, x, y);
    }
  }
}

Now our CheckerBoard can look a little something like this:

@SuppressWarnings("preview")
public class CheckerBoard {
  private static int MAX = 8;
  private final Space[][] spaces;

  private CheckerBoard() {
    spaces = new Space[MAX][MAX];
    forEachSpace(
        (i, j) -> spaces[i][j] =
          ((i + j) % 2 == 0)
            ? new BlackSpace(i, j)
            : new RedSpace(i, j));
  }

  . . .

}

Note: that, if you are anything like me, you aren't a fan of warnings. So here's a way to suppress them for the preview features we'll be using.

Multi-line Strings

Java eliminates all leading whitespace between newlines!
Luckily, I already had a scenario where I would not need leading spaces in my string anyways:

class CheckerBoardTest {
  @Test
  void shouldPrintBoardAsExpected() {
    final CheckerBoard subject = CheckerBoard.freshBoardWithTokens();

    assertThat(subject.toString())
      .isEqualTo("""
            Ω · Ω · Ω · Ω ·
            · Ω · Ω · Ω · Ω
            Ω · Ω · Ω · Ω ·
            · • · • · • · •
            • · • · • · • ·
            · ☺ · ☺ · ☺ · ☺
            ☺ · ☺ · ☺ · ☺ ·
            · ☺ · ☺ · ☺ · ☺
            """);
  }
}

The google format spec basically has no idea what to do with this…

Pattern Matching in `instanceof` (`instanceof` casting)

This is a really handy trick that I wish was introduced much earlier.

It is also reminiscent of a feature of the AssertJ testing library.

The key use of this feature is to prevent a manual class cast of a variable after you are only in a block of code based on the type of a variable.

So instead of:

public void method(final Animal animal) {
  if (animal instanceof Cat) {
    ((Cat) animal).meow();
  }
}

We can do:

public void method(final Animal animal) {
  if (animal instanceof Cat cat) {
    cat.meow();
  }
}

This method will set up a new checkboard and place the players' tokens in their starting positions. Since pieces should only be allowed to be played to the black spaces on the board, I can place pieces using the a wither to keep each space instance of my board immutable.

public static CheckerBoard freshBoardWithTokens() {
  final CheckerBoard board = new CheckerBoard();

  board.forTopThreeRowsOfSpaces(space -> {
    if (space instanceof BlackSpace s) {
      board.spaces[s.x()][s.y()] = s.withContents(BLACK);
    }
  });

  board.forBottomThreeRowsOfSpaces(space -> {
    if (space instanceof BlackSpace s) {
      board.spaces[s.x()][s.y()] = s.withContents(RED);
    }
  });

  return board;
}

To be fair, the cast here is not necessary. So if you can come up with a better use case, I'd be happy to hear about it in the comments!

Switch Expression

Our CheckerBoard class has a convenient toString method for a user friendly visual:

@Override
public String toString() {
  return streamSpaces()
    .map(space -> {
      final String strSpace = (switch (space.contents()) {
        case EMPTY:
          yield space instanceof RedSpace? "·" : "•";
        case BLACK:
          yield "Ω";
        case RED:
          yield "☺";
      });

      return String.format(
          "%s%s",
          strSpace,
          space.isRightEdge()
            ? "\n"
            : " ");
    })
    .reduce(new StringBuilder(), StringBuilder::append, (l, r) -> l)
    .toString();
}

That new yield keyword at work! I can essentially iterate over each space to yield a character.

More examples can be found here at this Baeldung article.

Issues

google code formatter breaks. It looks like it breaks on records, multi-line strings, and the yield keyword that occurs in the switch expressions
- To solve this, I think some motivated person could just start collaborating on Google GitHub repos for this. The spec repo The configuration repo
the maven compiler (actually, the JVM) requires the --enable-preview flag to unlock the features. This is an obvious red flag for usage in production code. It is hard to assess the risk of using these features as well. In the past, many features of the JDK that shipped as previews in earlier versions of Java have actually functioned perfectly. Will that continue to be the case?

Wrap-up

One cannot simply assume that preview Java feature will become integrated into the JDK long‑term.
The JavaDoc for the Record class even contains a disclaimer:

This class is associated with records, a preview feature of the Java language. Programs can only use this class when preview features are enabled. Preview features may be removed in a future release, or upgraded to permanent features of the Java language.

In the case of records, however, you can breathe easy, as it is officially integrated into Java 16.

As for the other features described in this article:

Feature	Java version introduced	Java version finalized
Pattern Matching in `instanceof`	14	16
Records	14	16
Multi-line Strings	13	14
Switch Expressions	12	14
Sealed interfaces	15	?

Sealed interfaces are still not officially being integrated. Even if they stick around, their syntax is subject to change. So that isn't a feature we were able to use here yet.

The other features that I listed as being integrated for version 16, have not changed syntactically since 15, (as far as I could tell). So with those, you're in the clear

Verdict

If you don't care about using the Google code formatter plugin for a while, and don't care about using sealed interfaces yet, you and your team can make the upgrade!

If for some reason you are still tempted to use the sealed interfaces anyways, I would strongly suggest not using them! It is not an officially integrated feature and could change or even go away.
A good example of this was the "Switch Expressions" feature. It was introduced in version 12 and overloaded the break keyword. This was changed to yield in version 13 to make more clear the intended behavior. Since it changed, it naturally needed to stay in preview in version 13, then finally was accepted in version 14. There's no telling what kind of iteration the sealed interfaces could still undergo.

Complete side-note | Speaking of features coming and going or staying

Sometimes, it is nice to declare a Function in a Java Lambda, but you plan to return a specific object regardless of the input. In the past, I have used an underscore _ to define the variable of non-interest. Java 9 had discontinued this from being allowed.
Which I found interesting, considering that the introduction of _ as a variable name, had the apparent intention of being used in lambdas for unused arguments.

While in our code bases, we have now switched to using double underscores __ for this, we also use Vavr. So a nice alternative might be to use Function1.constant.

DEV Community: Alessandro Aiezza

Favorite Git Things

My Favorite Git Tools and Tutorials

Tools

Tutorials

But why care about SOLID?

SOLID Principles in Kotlin

Some giants to thank:

My guiding steps:

The Uncoding: Elevating the Craft of Software Engineering

Introduction

How Did We Get Here?

Why Is Code Still Hard to Read?

The Philosophy of Uncoding

What Does "Right" Look Like?

Putting "Uncoding" into Practice

Where to Begin

The Tangible Benefits of "Uncoding"

1. Cost Savings

2. Risk Reduction

3. Faster Onboarding

4. Improved Employee Retention

5. Long-Term Scalability

Inspiring Your Team to "Uncode"

Strategies for Leaders

The Future of Uncoding

Conclusion

Idempotent

Of all the places to FINALLY understand OAuth

The Coding Language you Write Affects your Personality

My Italian Journey - Italian learning resources

Quali risorse usi per imparare l'italiano?

Youtube

Apps

Podcasts

Netflix

Tips

Shows

Books

Children's Books

Other Content

Other Ideas

Somebody has been coding in MY repo!

You want me to approve what?!

Those poor bears

That's exactly what's happening to me!

Goldilocks Syndrome

Going from "the bear", to "the balanced mentor"

Real-life example

Tips for finding that balance

Finally, its over

Are you seriously not using Java 15 yet?

Introduction

Conversion process

Change the Maven compiler plugin version.

Installing Amazon Corretto 15

Updating my IDE

IntelliJ

Eclipse

Using the JDK

Let's try out these Java 15 features

No more need for lombok here | Records

Notes for record

Necessary usage of the canonical constructor

Who's up for Checkers?

Sealed Interfaces

Multi-line Strings

Pattern Matching in instanceof (instanceof casting)

Switch Expression

Issues

Wrap-up

Verdict

Complete side-note | Speaking of features coming and going or staying

Notes for `record`

Pattern Matching in `instanceof` (`instanceof` casting)