List of article summaries
PostgreSQL and typeorm - Caching
With most web applications you can drastically increase performance by using caching for data that’s frequently read across network boundaries. This lesson will explore some common caching techniques, you’ll learn how some common tools and libraries provide caching for us.
While caching helps with performance it can also cause some surprises and bugs in applications and i’ll discuss some of those too.
How to run Monica personal CRM on Dokku
I left my home country right after university and I worked and lived in a few countries since then. I’ve met lots of amazing people but I’ve always struggled to remember contact details and important dates for everyone.
Find 20% of missing site traffic with plausible analytics and some proxying
Google Analytics (GA) has been a force in web site metrics since 2005. The metrics have always been incredibly useful but it’s a “free” product so you pay for it by providing all your site data to Google for tracking and advertising.
With Google Analytics your metrics are tightly coupled with tracking and advertising so when ad-blockers kick in to block tracking they also block your metrics!
The good news is that this is all fixable!
Open Telemetry in NestJs (and React)
Open Telemetry is good enough to use in production projects now and most cloud providers and telemetry services have integrated open telemetry into their products.
PostgreSQL and typeorm - Relational data
In this lesson you’ll learn about relational data with typeorm and postgres.
PostgreSQL and typeorm - Practical transactions
To understand what a transaction does for us and how to choose when one is required in…
PostgreSQL and typeorm - 9 Tips, tricks and common issues
To learn some tips and tricks to solve very common issues with typeorm and postgres…
PostgreSQL and typeorm - A glossary for database administration
You will learn about some things that you might come across when discussing database…
PostgreSQL and typeorm - Advanced Querying
After this lesson you will be able to recognise and use the most common querying…
PostgreSQL and typeorm - Storing single table data
In this lesson you’ll learn how to store, retrieve and update data in a single table in…
PostgreSQL and typeorm - Getting a local Postgres instance
- Set up a local instance of postgres for learning
- Learn where to get a production database …
PostgreSQL and typeorm - Intro to persistence
This course is designed to help you get into the world of persistence with typeorm and…
How engineers can help deliver software effectively
Delivery managers and team leads have the responsibility to deliver a software system via an engineering team.
Your customer wants every feature to work perfectly and they want it delivered yesterday. Your team wants to learn and grow.
It’s a tough role managing all the stakeholders and creators in a project.
Engineers can help drive great delivery by empathising with and supporting the delivery manager or leads in a project team.
Engineering systems for consistency and impact
Your most impactful engineering is done before you write any code.
It’s important to have some systems around how you approach problems to make sure you’re consistent every time.
These are some of the techniques I use to make sure I’m covering as many angles as possible when doing my pre-coding engineering.
How software engineers can avoid commoditisation
Engineers spend most of their learning time on technical implementation content. Things like new frameworks, languages or cloud platforms.
But turning solutions into code is a tiny part of what you do and it’s getting less valuable year by year.
As we’ve seen with “no-code” and tools like GitHub Copilot, the implementation part of our role is increasingly becoming commoditised.
You could generalise that the value an engineer brings to a team is their ability to analyse problems and synthesise context. The part of your role as an engineer that will never be replaced by “no-code” or AI is this high level cognition.
The true human aspect of being an engineer is working in a team and considering other people’s ideas, emotions and thoughts while solving these problems.
So shouldn’t you train these meta-cognition skills as much as you train the specific technologies?
Every engineer should spend time learning and applying general tools for thinking. These tools are applicable to almost all problems so the compounded payback on your invested time is huge.
Clearer thinking will amplify all the other skills you have and any frameworks or tools you learn will give you results for the rest of your career.
Like any skill, improving the way you think takes deliberate study and practice.
These are some of the tools and systems for thinking that I refer back to all the time.
20 questions for a valuable code review
I recently had an interesting discussion around the value of doing code reviews and the value of mandatory code reviews.
I think code reviews are extremely valuable and should be done by most organisations and teams.
A valuable code review will
- pass institutional knowledge around the org
- help all engineers grow their skills
- maintain quality in the face of all the other time pressures your team faces
But how do you keep a code review valuable?
10 Useful product-thinking lessons for engineers
Have you ever struggled to explain the business value of a piece of engineering? Like why a particular piece of tech debt needs to be paid down now?
Engineers can learn from the techniques and rigour that product management practice has created in the past few years to
- To show business value in their own engineering work where it’s not easy to articulate
- To empathise better with customers of the software their building
- To understand the business context you’re in
For example, how can you know that you’re building something useful for your customer? How can you convince others that you’re not ahead of your time with an engineering solution?
For engineers there are some product development lessons that will improve your empathy and communication with non-engineers in your org.
Minimum viable discovery and software estimation for engineering work
I recently had to estimate 6 months of work for a new product after just 2 hours of discovery. This is a short deadline for an accurate estimate and I felt uncomfortable providing a number.
I ultimately gave a gut feeling estimate for the work because that’s my job and we needed one by the next day. I did specify it was at least 20-30% wrong and highlighted the major risk I saw - a new third party integration that we had never integrated with before.
The whole scenario got me thinking about what works and doesn’t work for me when estimating larger pieces of work. Here are some of the thoughts, tips, tricks and learnings from 10 years of providing dodgy software estimates!
Which http status code to use for no search results found?
I was implementing a search REST API and was thinking about the no results status. There are a couple of options that are somewhat valid. There is no perfectly “right” answer and the discussion exposes care for API design, knowledge of http and care for developers who will be consuming the api.
10 RFP response signals to watch out for
When you’re reviewing RFP (Request for proposal) responses you make sure that the provider has met all your specified requirements. A provider missing a requirement on the proposal is a bad signal. Then you weigh the response details against each other and finally the price gets calculated and you choose.
But here are 10 specific signals outside of the standard stuff above that I look for.
Here are the things I noticed with some descriptions.
Refactoring conditionals to strategies (in .Net/C#)
I’m doing some work on a legacy code base and there are some common refactorings I do over and over. One of my favourite improvements is making long lists of conditionals easier to read and especially test.
I use the common refactor-to-strategies pattern from Martin Fowler to deal with these.
Deliver 30% more PRs to production by having developers own their own testing
Is testing “slow” in your team? Do tickets pile up in the “ready to test” column every sprint?
If you think that the testers on your team need to fix this you’re wrong!
In a cross-functional product development team balancing the cadence and handover between development and testing is often a pain point. Read on as to why this is team problem and it’s best resolved by getting developers to thoroughly test their own work.
Be careful of the JWT hype train
I’ve been researching using Node.js as a back end for a few months now and SO MANY Node.js articles, courses and project “starters” on GitHub suggest using JWT on your client facing API as a session token.
I think there’s way too much hype around it and people are using JWT because it’s shiny!