Last week, I finally posted the 3rd blog post in my Kotlin/JS blog series. I went into a demotivation zone where it took me more than 4 months to complete the almost finished draft of the blog.
The situation also discouraged me from writing my journal posts because I was ashamed of not finishing my blog even though I kept writing that I'll finish soon. Again, I broke the streak and now writing this journal post after 3 weeks.
That said, I've decided to not put myself into a pressured situation by posting a journal entry weekly. So I removed the word
weeklyfrom the post title.
API design
I've worked on developing mobile SDKs for most of my software development career. I have also spoken about building Android SDK few years back. One thing that is most crucial in SDK development is API design. It's a big deal that you're writing a piece of software that will be used by another developer rather than an end-user. Someone would evaluate your library or SDK in the way you would measure other third-party libraries before adding them to your project. I feel fortunate that I got to work on SDK development more. While developing just an application, developers tend to ignore the importance of public APIs and thoughtful design. After all, the code is mainly internal in the app.
Today, I read a great post - APIs as ladders by Sebastian Bensusan. I really liked the ladder terminology and the different stages of the ladder. It's not something that you read once and remember. Posts like this should be re-read during different stages of development to remind ourselves that we're still making good API decisions.
I read a similar post couple of months back from Jake Wharton (who doesn't know him? I don't even have to link to his bio here). He wrote about Slope-intercept library design where he explained that a library should provide simpler APIs to solve the majority of use-cases along with providing detailed and low-level APIs for those who want to achieve complex solutions.
There are more blog posts about API design I've added over the years to my pocket collection. I'll dig them and share them in my next journal post.
Recommended Reads
A post about the highly controversial topic of git commit messages. I cared a lot about
commitmessages and clean history during the early days of my career, but at this point, I'd pay less attention to them. In other words, at this point, I am happy to go with whatever the majority of devs prefer in my team or company. I have always been a fan of doingsquash and mergethough, and I use it all the time. It seems like the author has put in a lot of effort to write this post, and it's still worth reading even if you disagree with her.I'm not a smart-home person, but there is a new unified smart-home protocol work in progress called Matter. It seems promising if it actually works out in the end.
Adam Wathan tweeted about the successful profit-sharing model at
Tailwind Labsthrough a retweet of his original tweet about the announcement. He has also replied to some interesting questions in the thread below. Check it out!Kevin Schildborn posted his last post focused on testing in his Kotlin/JS discord bot series