One thing has become very apparent to me over the last few months - I have to enjoy what I am doing to have any chance of be successful at it.
Example:
My current client works with a tech stack that is not really aligned with my current core skillset and interests.
There is not a lot of room for creativity in the role.
Motivation becomes difficult.
Previously, I would power through and see out the contract.
Now, I am less willing to accept ‘just OK’.
My time is limited and I want a sense of fulfilment when I spend it…
So Long, and Thanks For All The Bugs
It can be frustrating to deal with bugs left by former colleagues.
It's easy to be annoyed at the obvious mistake that hindsight has revealed through that log, stack trace, and debugger output. Lay blame, get angry. Particularly when the pressure for a fix is on your shoulders.
There is an alternative.
You can view that bug through a lens of gratitude. Reframe it as an opportunity -
...to learn from a mistake.
...to understand more about an unfamiliar component, system, or technology.
...to find a new way to solve a tricky problem.
Research has shown that gratitude, and the positivity that flows from it, can provide a powerful tonic for your mind. Enhancing critical thinking, creativity, decision-making, and generally higher cognitive performance.
Exactly the tools you need in your belt when crushing that defect.
Not to mention it is just good for your general mental health.
Here is something I did not realise about the Actor Model - Actors send messages via mailboxes; not directly to each other.
So, Actor-to-actor communication is inherently asynchronously decoupled using messaging.
I stumbled across a new term today.
Co-opetition.
Competing, but in a supportive way. Everyone gets lifted up.
Very much from the mindset of abundance.
😉
You still need solid business requirements to build solid software systems.
Many teams move to Agile and think you can dispense with them.
Having a sketchy idea of what you are building and ‘being open to change’ is not a blueprint for success.
Write those requirements down. Do the business analysis.
It doesn’t have to be all up front. It doesn’t have to be perfect.
Adaptability is great. Pivot if you need to pivot.
But don’t expect a smooth journey if you cannot describe the destination.
Being creative is tough in a 9 to 5 setting. I am increasingly frustrated by it.
A work day that starts and ends with the punching of cards. It's a hang-over from the industrialisation of work. It's centuries old.
And yet here I am. A software engineer, trying to solve technical problems in creative ways. Still expected to conform to this pattern.
OK, I don't have to punch cards. In fact I am freelance, so I am my own boss in that sense. No HR. No 360 reviews.
But still, the age-old pattern of behaviour is expected by the client.
Contracts don't get renewed if you do not fit in the box.
And that is why I am trying something different.
With these very words.
Many developers are leaving database performance on the table by ignoring this feature.
I’m talking about Covering Indexes.
A covering index, also known as a covered index, is an index that:
- Contains all the fields in the query criteria (the WHERE & HAVING clauses)
- Contains all the fields returned from the query
With these two conditions met, the database engine can return using the index alone. This is achieved with an index scan. It does not have to access the table data.
This can provide a significant read performance boost.
But, as ever, there is a tradeoff.
Columns included in a covering index must be updated as writes are made. So, you may take a hit on writes if you use this a lot.
You will have to find a balance for your own usage.
Support for this feature is not universal across database vendors. PostgreSQL supports this through the INCLUDE keyword.
Try it out!
Use an outbox or tracking table if you are moving data between systems.
Even simple ETL processes.
Do it correctly and you get:
Simple decoupling of the extract phase
Better observability
Options for recovery when things fail
Your process will be much easier to support.
After a week or a month I see the gaps and the silly mistakes in my writing. I get a much better edit. Too late!
🤦♂️
It's easier to view things objectively with a bit of distance. You can see your errors but also see your improvement.
😉
Ever looked back at an old post, article, piece of work and felt ashamed ?
Well, congratulations !
Being ashamed of past work is a proof you are on a continuous learning path.
“Everything is energy and that’s all there is to it..
Match the frequency of the energy you want and you cannot help but get that reality. It can be no other way.
This is not philosophy. This is physics.” – Albert Einstein
——
I’m loving this quote today. Seems to resonate in the context of software teams and performance.
Collective energy is so important! 🤔
😉
@about_apis Open Source is always a great place to start - so many projects are desperate for contributors.
It can be as simple as small clarifications to documentation.
Current state: desperately missing Jira…
Which tells you everything you need to know about the tools available to the team I am currently consulting with.
🤦♂️
I struggled for some time with Test Driven Development.
I could see the potential benefit, but it didn’t feel natural. I didn’t have that time to invest.
At some point, I decided to brute force the habit. And I began to realise that you don’t have to write tests first...
I start writing a unit test. I get insight into how I want to use the component. I can iterate on the component's surface area (its API) - the inputs and the outputs.
Once I have that, the implementation flows from there.