DEV Community: Marco Davalos

5 Essential Principles for Highly Productive Developers

Marco Davalos — Mon, 23 Dec 2024 20:34:10 +0000

It is clear that seniority is not only about how skilled a developer is in a language or framework. It's about how our way of thinking changes through the experience. As a result, we make ours principles that are essential to us. After +10 years in the industry, here are some of principles I believe (IMHO) a developer needs to follow in order to become a highly productive one.

Measure Twice, Cut Once

Making sure you're on the right page, and aligned with your team, and other teams involved is a must to avoid: wasting time, money, as well as unnecessary awkward situations.

The time we spend investigating, evaluating the implications of our approach will be reflected in the quality of the code we write. It will be always faster to iterate your approach with your team, or in your head before you start, than to do it in the code.

KISS (Keep It Simple Stupid)

It is easy to write code that adds complexity when solving an already complex problem. This will make the code harder to review, test, and maintain. Complexity can be added by:

implementing unnecessary complex design patterns
adding a newer or better library without a valid reason
creating unnecessary abstraction
etc.

Common sense should be our guide, leaving our ego out of the equation. Your future self will thank you for it.

Least Privilege Principle

Asking for access to environments, repositories, secrets, etc. in order to accomplish your task might be tedious, especially in big companies that have slow processes. Sometimes less experienced developers can even take this personal as a sign of lack of trust.

Permissions always come with a responsibility, but also with a risk. The less privileges you have, the less damage someone who got access to your account can do. Trust me, you don't want to be the one who created a data breach in your company.

YAGNI (You Aren't Gonna Need It)

The temptation of adding additional functionality while working a new feature or fixing a bug will always exist.

However, more functionality also means more time, and most importantly: more chances of introducing new bugs. The later will translate to more time, and can also end up damaging the business side of the company.

No Hello

This is not a principle, but a good practice in team communication. Slack fatigue is real, so the fewer messages you send, the better.

Hence, don't start a conversation only with "Hello", "Hi", "How are you?", etc. Add your question or topic to the very first message to avoid unnecessary context switching for the other person. https://nohello.net/

Conclusion

Every developer might have their own principles, but no principle, or good practice is gonna make any difference if you don't know: how to work in a team, how to properly communicate, or how to properly handle/give feedback.

Soft skills, and being a good-honest person is the base of every highly productive developer.

Merge Faster to Ship Faster ⚡

Marco Davalos — Mon, 25 Nov 2024 23:12:54 +0000

Context

Software Engineering teams often share manually their Pull Requests to a Slack channel seeking a code review. This would not only speed up the review process but also boost productivity, increase team collaboration work visibility.

A year ago I got tired of copy pasting the PR info into Slack, and not being able to see its status with a quick look. prbot was born as a Hackathon to solve this issue. It ended up being used and loved by most of engineers at work.

I really enjoyed working on it so I decided to improve it and make it a product to keep coding cool and useful features around it.

Product

https://prbot.app

Even though the initial idea was simple, it kept evolving to what it is now:

Today's prbot mission is to enhance and speed up code review process, by automating Pull Request sharing, keep them in sync, and much more.

Features

Automatic Slack message
Synced Pull Request Status
Synced Reviews Status
Multiple Channel Support
Customizable Message Format
Advanced Settings

Configuration

Your config is a yaml file that you can put anywhere.

slack:
  defaultChannelID: "00000000000"

  repositories:
    backend:
      channelID: "00000000000"
    front-end:
      channelID: "00000000000"

  messageFormat:
    showSizeEmoji: true

Next Steps

I'm exited about the upcoming features like reminders, codeowners suppot, Microsoft Teams support, etc. However, they won't matter if you won't use it so I would love to know the features you would like to see in the prbot next releases.

How's your code review workflow? Tell me about it!

Happy coding!

How To Organize Golang Cloud Functions Code

Marco Davalos — Mon, 07 Dec 2020 15:21:43 +0000

On our journey to build the next billion dollar app, we decided to use Cloud Functions to write the backend logic in Golang. So thinking about how the hell we were gonna organize the code, was one of the first things we went through.

The only thing we knew for sure, was that we wanted all code in a single repository, in order to speed up the development velocity.

This is what we came up with:

A Go module per function

.
└── functions
    ├── awesome
    │   ├── awesome.go
    │   ├── go.mod
    │   └── go.sum
    └── marvelous
        ├── marvelous.go
        ├── go.mod
        └── go.sum

Having a Go module per function enables every function to manage its dependencies independently.

This avoids annoyances like making other functions stick to an older package version, or breaking other functions by upgrading major versions.

Relative imports

However, there's shared logic between functions that needs to be in common packages, and not having the functions within the same module makes it tricky to use them from the functions code.

Here's where the replace directive comes to the rescue, allowing us point an import path to another module located in VCS (GitHub or elsewhere), or on the local filesystem with a relative or absolute file path.

module github.com/example/functions/marvelous

go 1.13

replace github.com/example/functions/pkg => ../../pkg

.
├── functions
│   ├── awesome
│   │   ├── awesome.go
│   │   ├── go.mod
│   │   └── go.sum
│   └── marvelous
│       ├── marvelous.go
│       ├── go.mod
│       └── go.sum
└── pkg
    ├── compliments
    │   └── compliments.go
    └── go.mod

package marvelous

import (
    "fmt"
    "net/http"
    "github.com/example/compliments"
)

func CallMeMarvelous(w http.ResponseWriter, r *http.Request) {
    text := compliments.Say("marvelous")
    fmt.Fprint(w, text)
}

Vendor directory

Even though for development purposes this will work just fine, when the time to deploy the function comes, this won't cut it.

Executing gcloud functions deploy from the function directory, won't upload the pkg directory since it's located in a higher level, causing the above error:

OperationError: code=13, message=Build failed: go: github.com/example/functions/pkg@v0.0.0-00010101000000-000000000000: parsing /pkg/go.mod: open /pkg/go.mod: no such file or directory; Error ID: 03a1e2f7

To avoid this we create the vendor directory before deploying:

go mod vendor

and a .gcloudignore file, to use the vendor approach by not uploading the go.mod and go.sum files.

go.mod
go.sum

Now all the function needs is to be built and run is within the directory. Additionally the **/vendor path can be added to the root .gitignore.

Conclusion

We are not Golang experts and it might not be a perfect approach, but it's the most elegant we found so far.