DEV Community: Freddy Hidalgo-Monchez

What Are Your Engineering Principles?

Freddy Hidalgo-Monchez — Fri, 01 Dec 2023 18:25:33 +0000

In a previous post, I spoke about how engineering scope influences a project. I believe that principles are the undercurrent to those scopes.

What Are Engineering Principles?

Engineering principles are the rules and beliefs that govern our work. They make up our unique approach to development, analysis, and problem-solving.

Like microbes living in our gut: we all have them, we just might not understand what they are and how they influence us.

Why Are Principles Important

As software engineers we're asked to think deeply about a huge range of topics, and often expected to excel in all of them ("testing, security, design, tech support, operations, deployment, optimization...")

The truth is, that's not possible. Not at 100%.

Although all engineers have a common base of concerns (e.g. we all care deeply about working solutions), there are some questions we naturally gravitate more towards than others, some areas that we're truly passionate about and are ready to die on a hill for.

When we collaborate with different people from all walks of life, our principles collide. And it's in that short encounter that we have a golden opportunity to mesh together our principles to build something great, or as is sadly quite often the case, end up debating for hours with little to show for.

Before we can start leveraging our principles, I think we have to really think about what our principles are.

My Engineering Principles

Every engineer has their own unique blend of herbs and spices that help shape a meeting. What do I bring to the table? What are the metrics that I evaluate myself with? What does quality mean to me?

These are my engineering principles so far:

Efficiency
- Striving for solutions that yield the highest value with the lowest possible cost
- Creating real value for stakeholders
- Holding myself accountable for my decisions and the team's decisions
Growth
- Continuously questioning, learning, and improving
- Experimenting with new ideas
- Looking past the status quo
Transparency
- Communicating thought process, blockers, concerns
- Being honest and open, especially when it's uncomfortable
- Showing work early and often

Why these three? Because the people I've seen create high value at an insane speed where the one's who were extremely transparent in their work, strived for efficiency in the solutions they chose, and fostered an environment of learning and experimenting.

This is in contrast with other great engineers I've worked with who fostered opposing principles, and although still delivered quality work, did not have an impact at the same rate or depth.

Opposite Principles

If Efficiency's main concern is building just enough for the problem at hand, the other side of that coin is Performance, as defined as striving for the highest performing solution. The two often come at odds, especially when planning for the future (e.g. will our solution still work well in 3 years from now? Should we add that one more thing to make sure?).

Similarly, I've seen Growth's counterpart often be Stability, whether that's through the standardization of practices or establishing of rules and structure. Incorporating new learnings into repeatable processes is crucial when wanting to achieve a predictable and stable level of quality.

I've found Transparency's opposite cousin to be Focus. That might sound strange, but think back to when management withheld information. What was their underlying reason? What was their concern? I would bet that they most likely feared people would react in a certain way that would ultimately affect the team's focus on their work.

A Balancing Act

I believe all principles, when balanced properly, have a positive impact. For example, Performance, Stability, and Focus are crucial in certain teams and organizations across different stages, and at time could be even more beneficial than say radical Efficiency, Growth, and Transparency.

Regardless of what our engineering principles may be, the whole point is to realize that they are all valuable and that by harnessing their differences, we can achieve a better, more balanced solution.

What are your guiding principles at work? What's your north star or engineering compass?

How I Manage My Projects: A Step-By-Step Guide

Freddy Hidalgo-Monchez — Sat, 16 Sep 2023 23:19:26 +0000

There are so many tutorials on how to build stuff, but much less on how to actually manage what you're building - whether that's a quick weekend day hack or a month long project.

That's a shame because I find that having a solid project management system in place can be a real game-changer.

It kickstarts your ideas, keeps you aligned with your goals, and lets you stay laser-focused during development.

So, here's what's been working for me over the past five years."

Step 1: Requirements

I kick things off with a simple spec sheet:

What's the goal: What's the project's main goal or purpose?
Why build this: Why is it important to undertake this project? Understanding the underlying motivation helps shape the project's scope
Requirements: what are the critical features to consider the first version complete?
Phases: what is the essential work for each iteration? I try to keep the first as ridiculously small as possible to build momentum quickly
Mockup: what does this look like? The goal is to get an idea of what the project should look like. On bigger projects it can also help guide the backend work (e.g. what type of data do we need, format, etc.)

Step 2: Architectural Documents

Once I know what needs to be built, I'll outline what kind of architecture can satisfy those requirements as efficiently as possible.

This is where I'll look at non-functional requirements and carefully think about the scope.

What is critical? What can wait? What's the bare minimum?

I do this early on because it'll determine the pieces I need to build the project before I write a single line of code.

Essentially, it lets me code with an uncluttered mind knowing that the big questions are partly answered.

After narrowing down how the system should behave, I'll think about the technology that I can use.

That's where Architectural Decision Records come in. These are documents that clarify the reasoning behind decisions made.

This step might feel like it'll just slow down the process for little gain, but I found the outcome to actually be the opposite.

Without this crucial planning step, I find projects tend to easily derail and can stretch from weeks to months. It's even worse on solo work where you have little accountability.

The power of these docs to clarify thought and keep focus is huge!

Step 3: Feature breakdown & Estimates

Almost all projects I've seen break down their features into tasks - this is nothing new. The part I find extremely useful is estimating time and risk.

For each task, I'll write down how long I think it'll take and how risky the task is.

I define risk here as how probable it is that the task goes over the time I estimated.

I add up the hours and that's my best estimate. I'll multiply it (usually by a factor of 2) and I have my worst estimate.

This serves a few purposes: it helps create an estimate that is bounded (best, worst), and helps prioritize what to work on.

Step 4: Scheduling

Equipped with an estimate in hours and days, the next step is to simply add it to a schedule.

I find this is important because it makes the deadline real in my head. It also keeps me regularly checking mentally if a task fits within the given timeframe.

I keep this page open throughout my development:

Now we know what we're building, how we're building it initially, and how long it's going to take.

Next, we need to visualize the work.

Step 5: Visualizing work

I like using a Kanban style board (Trello has been my go to for its simplicity) that has the following:

Backlog: tasks that pop into my head while working
To Do: tasks I outlined in Step 3 or pull from the backlog based on priority
Doing: what I'm currently working on
Done: what's done (useful for review at the end of project)

Here's my productivity secret sauce, on every task title I add the following::

Est.: the estimated time for the task
RT: the real time it took to complete
Tag 'Ahead' or 'Behind': is the real time below or above the estimated time?

Step 6: Tracking the work

Right before I start working, I start my timer and place it in a separate screen so it's always in the corner of my eye.

Seeing the time pass helps my mind remember that time is a precious resource, even if it may feel like there's plenty of it.

Once the task is done, and this part is super important as well, I'll update the task's 'RT' on the board and set its tag to 'Ahead' or 'Behind'.

Updating tasks as I complete them gives me instant feedback on how much time is left for the project.

That type of awareness ultimately guides future tasks: can I afford to go deeper in this area? should I leave this task for the next phase? etc.

NOTE: All of the previous steps wouldn't amount to much if it wasn't for this step. Tracking how long each task takes might seem like a lot of context switching, but the cost is minimal compared to the gain in awareness!

Step 7: Retrospective

Once the feature is complete, I'll update the schedule with the real time it took for the project to be completed:

In keeping with the spirit of agile, this is where a mini retrospective takes place: what went well, what could be improved for the next feature, what were the biggest time sinks, etc.

Were all those steps really necessary?

Well no, nothing is really necessary.

But that question should be rephrased to:

"Is finishing the project as efficiently as possible really necessary?"

If the answer is yes, then these steps go a long way ensuring projects finish on time.

And I don't know about you, but I really ❤️ finishing projects on time 😜

Working examples

Repositories: Express app, Django app
Documents for the projects: Notion notebook
Deployed Apps: https://my-repo-stats.fly.dev/, https://my-repo-stats-python.fly.dev/

Cover photo by Dan Burton on Unsplash

How I Increased My Team's Productivity By 40%

Freddy Hidalgo-Monchez — Fri, 18 Aug 2023 13:19:09 +0000

I've been focusing a lot on productivity and habit building for over a decade now. Throughout the years I've tried many different techniques and I've had a good amount of success increasing my personal productivity.

Last year a random thought crept up:

As a software engineer, could I use the same techniques to increase the overall productivity of my team?

The Environment That I was In

I've learned that the groundwork needed to inspire long-lasting change is deeply rooted in how a team interacts with each other. From my experience, there are no shortcuts here.

Luckily, I was on a team that already had a strong innovative culture.

What I Had Learned So Far

I've seen many initiatives started by tech/team leads slowly fade away after a few weeks.

Or worse, the initiative keeps going despite its lack of effectiveness!

Too often I've seen the weak results be blamed on the team's apparent lack of discipline or experience.

A mentor once told me: "OK ideas have to be nudged. GREAT ideas spread like wildfire."

What To Improve

There were two areas I saw the team could improve on:

Speed: Less time spent from when a work item/ticket was worked on to when the pull request was merged
Focus: More time spent on work that produced high value for the stakeholders

The Plan

Another good lesson from that old mentor was that the most effective strategy for change is to prove before preaching.

So for the next month I tried various different techniques that I believed would yield an increase in speed and focus.

Some didn't move the needle much, but some were a complete game changer.

Here are a few techniques that proved to be the most effective:

Strategy Documents

For trickier issues, I would write a short plan of how I was going to solve a problem and why I had chosen that specific technique.

I then shared it with the team to gather feedback and consensus around what was being built. This is what I came to call a strategy document.

This type of feedback is nothing new, but it's something that's normally left for the Pull Request stage or covered in a daily/meeting.

My hypothesis was that by collaborating asynchronously and as early as possible it would decrease the time spent on coding and PR reviewing.

A nice side hypothesis was that it could potentially welcome a more diverse set of stakeholders to give feedback (clients, product owner, managers, directors, etc.).

Weekly Team Objectives

For our daily work, we tended to just pick work items we were interested in or followed what we had completed before.

This created mini-silos were engineers would establish residency in certain parts of the codebase.

With weekly team objectives, my hypothesis was that engineers would naturally switch their focus to the objectives meaning more collaboration and higher impacting work.

Small Pull Requests

Everyone already knew that small PRs were the way to go on our team, but there seemed to be hesitation, maybe even a lack of belief that it was worth it.

I had already seen this work very well in a previous team, so my hypothesis was that by showing the value of my super small PRs I would get more teammates on board.

The Results

Once I started implementing these changes for my own work, my teammates, curious bunch that they are 😁, started asking questions.

Is it ok to merge changes that are not completely finished? What should be in a strategy document? Where are those team objectives you were talking about?

That's when I knew these ideas had potential to make an impact.

In the next month, my teammates started trying these techniques and asking more questions about the process.

By the end, we saw a decrease of 40% in time spent from implementing changes to merging pull requests for the entire team.

Naturally our deployment frequency went up as well, and given we had achieved this through reviewing each other's solutions deeper, our change failure rate also went down.

But most importantly, our team felt substantially more productive and dynamic.

It's somewhat ironic that by slowing down to invest more time in collaboration before coding, we were able to achieve both a quicker output and a superior codebase compared to our previous approach.

If you do the same, will you see the same results?

Maybe. I don't know.

It's not about the practices or tools you put into the place, it's about that word every engineer is sick of hearing, culture.

The techniques were just an accelerator for what was already there.

I mean, you might even see negative productivity if your team does not have enough trust or cohesiveness. Readers beware!

Sadly it's an area of tech that I feel not enough people are working on: how to build real innovative culture.

A few paid lunches and go-karting with the team each quarter isn't going to get us very far.

But that's for another post 😃

Have you initiated productivity changes in your team? What were the results? What did you learn from that experience?

Photos by:
Jannes Glas on Unsplash
Steven Lelham on Unsplash
Scott Graham on Unsplash
Mitchell Luo on Unsplash
Ian Taylor on Unsplash
Priscilla Du Preez on Unsplash
Brooke Cagle on Unsplash

Which Engineering Scope Are You Using?

Freddy Hidalgo-Monchez — Thu, 17 Aug 2023 13:10:17 +0000

In the few years I've been working in tech, I've started to see common patterns that engineers adopt to solve most problems. For example, here's a popular problem with different approaches:

Problem: The way we clean our client's archives is complex and messy.

Craftsman's scope - How to make the piece better?

"Maybe we can simplify the clean up script. Can we possibly use another language with built-in features we can leverage, maybe one with less dependencies?"

It's the stereotypical engineering work we find in TV and movies. This is the scope that can spend days or years focused on extracting +5% of efficiency out of a component. It's where algorithms are born and faster compute time is achieved.

Architect's scope - How to make the system better?

"Since the data is spread out evenly, maybe we can create a centralized service that cleans each archive at a certain frequency?"

The Architect scope is focused on arranging the pieces to produce an elegant system. Tools for this problem are still rooted in technology, but seen through a lens that encompasses more abstract concepts like patterns, relationships, coordination, and communication.

Entrepreneurial's scope - How to serve the client better?

"Maybe we should confirm that our users even need this data. How often do they access it? Can they live with only the last X number of backups?"

In this scope, technology is simply a giant lever to fill a real need. Communication and vision are the most useful tools here since uncovering needs and addressing them efficiently is much more about understanding than technology's use.

Finding a great solution requires the right mix

I believe much of what plagues software engineering is that we simply copy roles from other disciplines, but we don't organize our thinking around what those roles actually mean. Or ignore the fact that some scopes tend to misalign with people's preference.

Titles like "architect", "senior engineer", and "manager" should technically embody one scope over the other, but I rarely see that level of separation in thinking. Especially when those positions are filled by engineers who have spent years looking at problems deeply through a Craftsman scope.

"If you've ever had a manager spend hours preaching the benefits of a mapping library, while you have yet to have a talk about your career progression, you can see the scope misuse at work"

My hypothesis: When the three scopes are used effectively, teams are much more productive in achieving the best possible solution to a given problem.

Have you seen these scopes in the wild? Do you lean towards one more than the other?

Image references:

Photo by Markus Spiske on Unsplash
Photo by Rob Lambert on Unsplash
Photo by ThisisEngineering RAEng on Unsplash
Photo by Clem Onojeghuo on Unsplash