Let’s consider two engineering managers, John and Jane. They have the same seniority, they both work on similar projects in similar conditions and their teams are both terribly smart.
John insists on personally reviewing and approving every change, no matter how small. This doesn’t just concern the codebase: if an engineer wants to try a new productivity tool with the team, they have to go through John. If the team wants to move an internal meeting to a time that better suits everyone, she has to go through John. …
During my career, I’ve had the honor of observing and being part of tens of engineering teams as a consultant, IC and manager.
Obviously, not all of these teams were equally effective at reaching their goals: some worked like perfect machines, others fell apart at every little problem, and most of them were somewhere in between these two extremes.
One would be tempted to explain these performance differences through a mere gap in technical skills — simply put, some people are more skilled than others and get more done, faster. …
Originally published at https://nebulab.it.
As an eCommerce consulting firm, we know the value behind a custom store implementation: not going with a SaaS solution affords you maximum flexibility and endless innovation opportunities — there’s nothing a good development team can’t do.
For digital brands, this can be powerful: when your platform doesn’t limit you, you can implement whatever you have in mind, and create even stronger bonds with your customers.
However, there are also downsides:
Once the number of decision-makers in a company increases, it becomes increasingly more difficult to gather feedback and get stakeholder buy-in on organization-wide changes and policies.
Conference calls and instant messaging, the two communication mediums of choice at most modern companies, are not the right tool for the job: their fast-paced nature and volatility makes it difficult for people to collect and organize their thoughts before sending them out to their colleagues for evaluation.
For most of us, it takes hours or even days to analyze a new idea from all possible angles and structure it properly, but in a chat or a call, you only have minutes to do it before losing people’s attention. This makes these tools the perfect place for quick back and forth, but not a good choice for decisions or projects with a wider scope. …
“I think I can run the demo on my own, you don’t need to be there.”
That’s when I knew she didn’t need me anymore. Somewhere, deep inside, I felt a novel, weird sensation: it was pride and… what else?
At the time, I was the CTO of a tech startup, and I had been training Carmen, our frontend lead, for well over a year now. Carmen was a brilliant engineer who now led a team of eight, tasked with developing three different products. …
This is a follow-up to UIs for Machines: Design Principles for HTTP APIs. One of the principles outlined in the original article is Evolution, and it suggests that developers should strive to keep their API relevant and up to date without sacrificing usability and backwards compatibility.
While this is trivial to accomplish for GraphQL APIs, where one can always add fields and never touch old ones with minimal performance overhead, it’s not as simple for RESTful APIs, where the API has multiple endpoints that can be deprecated independently and resource attributes are usually computed regardless of whether the client will actually need them or not. …
There’s no debate around the fact that good API design is an art. When we stumble into a properly designed API, we can feel it. Just like good visual UIs, good APIs are not just beautiful, it’s functional and it saves everyone’s time. With this mind, it’s not a stretch to say that APIs are, in fact, UIs. They’re not just meant for machines either: since there are people programming and using those machines, creating an API that users are delighted to interact with is a deliberate choice of its development team, and one we ought to make.
There are many resources about design principles for visual UIs, as well as a lot of good examples to take inspiration from. When it comes to APIs, on the other hand, there is a lot of documentation explaining the different protocols, languages and frameworks for their implementation, but nearly not enough material on the underlying principles and choices that make certain APIs a joy to work with and others a complete nightmare. …
Roma ha sempre esercitato un fascino indescrivibile su di me. Fa collezione di difetti, ma con la sfacciataggine di chi sa che tutto gli sarà perdonato, o forse con la distrazione voluta di chi neanche ci pensa, alle cose, di quelli che portano i calzini di due colori e non gliene frega niente.
Dissi questo ad Alice. Stavamo lì, seduti a un tavolino del nostro bar preferito; anzi, l’unico a cui fossimo mai andati.
Le dissi anche che Roma mi ricordava lei, con quell’aria di chi ne ha viste tante e ancora si espone.
Tutto questo lo avevo preparato a casa, si capisce; e fui subito pronto ad ammetterlo, e la feci ridere. Ma questo non rese il momento meno bello. …
The open-source community has done a great job of promoting good documentation as a necessary trait for the success of a software project, whether it be a utility library, a larger framework or a standalone program.
A project worth using will usually provide excellent documentation resources that go into different levels of detail: the maintainers of a library, for instance, might publish both a user’s manual that covers common use cases and a more detailed API reference for those adopters who want to inspect the inner workings of the code.
But even with all the work we, as a community, are putting into documenting our projects, there’s an incredible underappreciation for the teaching potential of error messages. I believe that, by making an effort to put ourselves in our users’ shoes, we can leverage this potential to create products that are easier to use on a daily basis and debug when something goes wrong, making our users happier. …
2018 has had lots of ups and lots of downs for me. I’ve never published an annual review before, but I thought it would be fun to try.
For me, the greatest value of this exercise lies in the ability to look back at the commitments I have made publicly and see whether I was able to honor them or not.
In February, I broke up with my significant other, whom I had been with for three years. It was one of the most painful and challenging experiences of my life, but it was also transformative.
Because I was hurting so badly, I decided to try therapy — it turns out it was one of the best decisions I have ever made. It taught me a lot about myself and what I could improve in how I dealt with other people. Most importantly, it taught me to recognize patterns and act on them before it’s too late. …