Reports. It’s often one of the first features developers are asked to build by the business. Once someone has data, what do they want to do with it?
That’s right — view it.
Many engineers approach reports in a use-case particular way.
They’ll get a requirement such as “create a .csv report that displays all purchased items from the store” and they’ll go and create that particular feature.
The next time they may get a request to “create a .csv report of all users belonging to the account” and they’ll go and create that feature as well.
As time goes…
I’m an amateur blogger and a professional software engineer.
I initially started blogging on my personal website to collect my thoughts and build up an “online” presence. The standard advice given to new engineers was “start a blog so people know you’re passionate”. I wanted them to know.
The only outcome I cared about was helping others and having something tangible to point to when I got asked “so what do you like to do in your spare time” during an interview — a classic two birds, one stone scenario.
In 2016, I looked at the analytics on my website…
Software is complex, and in many cases, complicated. Even simple systems can have a lot of moving parts that interact with each other in mysterious, unintended ways.
If you’re lucky, these interactions don’t cause serious issues.
If you’re unlucky, they do and you get a bunch of errors.
If you’re very unlucky, you don’t get any errors, letting the issue fester for years while it stealthily wreaks havoc on your data.
Here are just a few of some of the memorable bugs I’ve seen over my career.
My project manager sent me an email saying that a user had reported…
Startups survive because of their agility and speed — their ability to pivot and move quickly. They measure their execution tempo in hours, days, and weeks. This allows them to maneuver around larger lumbering organizations that operate in tempos of months, quarters, and even years.
In environments like this, speed is king. Rapid time-to-market is the startup’s competitive advantage. Without it, you can’t get the tight feedback cycles that make iteration possible.
Achieving these speeds isn’t easy — it requires startup engineers to make a lot of sacrifices (both personal and technical) and take plenty of shortcuts. …
First off — I am not a lawyer, and this is not legal advice. I may be wrong in any of this. Use this for entertainment purposes only, and get an actual lawyer if you need one.
Over my career as a software engineer, I’ve signed a handful of employment contracts. I used to sign them without thinking, but as I grew in my professional career, I became more and more aware of the limitations (and benefits) contracts provided.
It led me to believe that all software engineers should be aware of what they are signing. In the US, provisions…
Software development is full of mantras that are chanted by developers of all levels as prima facie evidence that justifies and proves the rationality of their decisions.
Who amongst us hasn’t heard people or told people to YAGNI, DRY, or KISS? They’re popular mantras because, when followed properly, they work to guide and nudge thinking towards more effective development and programming.
However, they have a dark side.
Because these terms are intentionally vague and broad, they can be misapplied or over-applied in many situations. These memes are then used as justification to continue applying the wrong approach to a problem.
I’ve been fortunate enough to see a lot of first-time managers take up the responsibility of managing their teams for the first time. Almost like clockwork, they generally fall into a series of common traps and early mistakes. The good ones learn from them — the bad ones repeat them.
It’s unfortunate but expected — management is an entirely different skillset than being a good individual contributor.
In many companies, a person enters their first management job without support or mentorship — a trial by fire. Startups often grow so rapidly that the initial contributors rise to management positions for…
I was once the Director of Engineering at a startup that was always busy, busy, busy! We had people to help, processes to fix, and product to ship. Every day was a fire or pivot.
Strategically we had some key skills gaps that I needed to close, fast. I knew the only way to do it was to increase the size of our team, but given all of the other things going on, hiring kept falling by the wayside.
Engineering, architecture, management, company strategy, wouldn’t get done if I focused too much time on hiring, and yet hiring was critical…
Most tech leaders who have been in an early-stage startup have encountered this question: “Do I need an engineering manager?”
It’s a tough decision. Most early-stage startups aren’t flush with cash. Every dollar they spend on an “expensive” manager is one less dollar they can spend on a direct contributor to the codebase.
Furthermore, hiring the wrong manager can be incredibly damaging to the culture and organization. …
Process is an afterthought for many tech startups and an intake process is often the last thing on leadership’s minds.
After all, they haven’t needed it so far. In the day-to-day chaos, things have happened and progress was made just fine without any formal process.
They may even have started thinking that an intake process isn’t even necessary and would just slow things down. Perhaps they’ve come to believe that their team has somehow found some special trick to make such process completely unnecessary.
They deceive themselves. It’s understandable how inexperienced engineering leads get lulled into this dangerously false sense…