I’m always learning new stuff, and when I get time, I try to write up what I’ve been learning, coding, reading and much more.
The use of empty strings when used to indicate a null value or lack of value, when the language you're using has a better way to support that will, will lead to bugs and hard to maintain code. With very few exceptions, empty strings should be avoided at all costs.
I've been through the microservices transition in mature startups, large corporate and small businesses. I'm about to embark on another one with another corporate. So, what have I learned? What has worked well?
The handy features in async/await make callback code easier, but is it making your code slower?
I’ve been thinking a lot lately about process and team efficiency.
As I continue my journey into the world of JavaScript (JS), one technique that was new to me that I’ve found using a lot is a technique called destructuring assignment.
Lately, at my new role, I’ve been doing a lot of work with Azure. Being #Ignite week, I thought I’d share some of my impressions and learnings so far. For context, I’d not used cloud services in my previous role, and before that, I had used a fair amount of AWS.
Target State Architecture (TSA) is your architecture, perfected. However, the problem for most companies is that it lives in the back of the mind of the most senior or long-serving engineers. Maybe the CTO knows, but not many others would. Some engineers might know bits of the future and most likely only know bits of the present.
GraphQL is something we use internally at my current employer and it was new to me upon joining. I’d heard of it, new there was a bit of hype around it, and have (spoilers) turned out to quite like it.
At my company, I have been tasked with creating and/or extending various fringe services. These are typically written in TypeScript running in a Node.js environment. So what have my experiences been so far?
I've just finished Give and Take by Adam Grant. My manager suggested I read it and leant me his copy a couple of months ago. I've just put it down, and I must say, it's one of the best (and only - don't judge) books I've read in a long time.
An experienced software engineer, or any professional can feel just as lucky as they come to a problem they've seen before, and solve it swiftly.