On-call

Leigh asked:

Anyone read or have any good advice for organising out of hours cover for small dev teams managing their own services? E.G. how to fairly compensate for overtime, organise rotas, manage escalation of issues, etc?

Read More about On-call

Combining an LLM and a Rules-based Chatbot

A rules-based chatbot allows for rapid development. Adding rules as you go, some of which can contain complex logic. Rules-based systems do not use large amounts of computation and especially don’t require GPUs, cheaper running costs and more responsive replies. As powerful as rules-based chatbots are, they also come with downsides. Creating rules is time-consuming and challenging to cover all the scenarios. The rules files quickly become quite large and cumbersome. Workarounds such as having a final catch-all rule can somewhat mitigate this.

Read More about Combining an LLM and a Rules-based Chatbot

Chatbots

I’ve been working on chatbots on and off for a while now. The other day, I received a question about how I built the latest Chatbot.

“I love the Chatbot, and it has been something I’ve been trying to replicate. There is so much noise. I’m finding it hard to find a good solution. I’d be grateful if you could point me in any direction, tools or what to search for.” 

I had always intended to write about it. The scope may have expanded a little since then into a short series. This post covers some background on chatbots, a few principles for conversational interfaces and building a basic chatbot.

Read More about Chatbots

Language choices

Very much a part two of ‘Mistakes I’ve made in my career (so far)

The Question

My Experience

I am expanding on my Twitter thread.

At a previous start-up. Greenfield project. New team. We got started with building version one. We began as a free for all. The mindset was the best tool for the job. Resulting in every service being in a different language. Node, Go, Haskell, Python.

For the MVP, everything was in containers, so deploying and running the system was not that bad. Maybe a little too complex for the features we had but nothing too horrible. Engineers worked on the same service most of the time. No one was switching back and forth between services. Maintenance or anything post-demo got zero thought. We needed to ship sometime that vaguely worked.

Post MVP. Maintenance was a problem; only certain people could work on certain services. Hiring was the other major problem and ultimately forced the issue. No one knew all those languages. Even people that knew two or three of them were not at the same level in all the languages. Mentally switching between different languages is tiring.  

We took the difficult decision to standardise on Go. The largest and most active service used that. Everyone on the project would work in Go at least sometimes. We still had some other languages but only for specific uses. For example, python for data science tasks, but the default was Go for everything. We took the hit of rewriting services not already in Go over time. In the end, it cost a couple of months to get back to where we were for the MVP.

I do not think anyone thought the MVP code would survive long-term. I certainly did not. We were always going to rewrite, expand the services and remove all the last-minute fixes we needed to get the project out the door. If those services had already been in Go, that would have been an incremental refactoring process. We would always build a shippable version of the project. Instead, we broke everything and could not ship anything for what seemed like aeons. in start-up time. We were lucky and only needed to demonstrate the project on one or two occasions. Each time was a painful experience until we had finished the rewrite.

Hiring was more focused. We had less of a laundry list of skills and languages—this ultimately allowed us to hire some junior engineers. You can not expect someone at the start of their career to be able to write production code in three or four languages. Maintenance was more manageable with only a single language. Everyone in engineering could help each other. The general quality of code went up.

Painful lesson learnt.

At my current place we started off standardising on Node. Not because it is my favourite language but because the centre of gravity in the project is around Node. The same with yarn.

Cold Calling

“Be good to hear your thoughts on something I think could benefit you – can you spare a minute?”

I get a regular stream of messages like this, sometimes multiple ones a day. The text provided zero context. About the only thing I learn is some random person I don’t know wants to have a call with me. A half an hour call isn’t only half an hour of my time. I need to read your material to prepare questions. Check the service is relevant to the company.

I know times are tough. Running a business is challenging at the best of times. These aren’t the best of times. Cold calling is hard. Messaging many people hoping a few will say yes, has got to be pretty soul-destroying work. Low effort, one-line, no-context messages don’t put me in the best mood if I reply to you. Block, report as spam and move on seems a more straightforward response.

Seeing generic messages like these are so frustrating. I’m an optimist. Anyone that starts a business is worth celebrating. I want you to be more successful. I know you can do better.

I’m going to look at your message and ask a few questions:

Is your product relevant to the company? Have a quick look at the company’s website to check we are the correct type of company for your product. if we are in the wrong area or have no use for your services. Messaging wastes your and my time.

Will your product save time or money? Tell the story of how you will make my life simpler. I’m always interested in hearing about that.

How can I get an overview of your product? Give me a one-page summary of what you offer as an attachment or a link to a landing page. Make it easy for me to see the value you can provide.

Resources for New Managers

Expanding on this comment. So you switched from building things to management. Read these to understand your new role:

Here are a few resources I found useful when making that switch.

Newsletters

Blogs

(Both for newsletters and blogs. RSS is your friend to help keep on top of things. I use Feedbin)

Conference

Books

Community

Other Resources

More Links