Andy Crouch - Code, Technology & Obfuscation ...

Talking Or Walking Away - Approaches To Maintaining Productivity

Frustrated Woman Biting Pencil

Photo: jeshoots.com - Unsplash

Sometimes it is best to walk away.

I am not talking about ending a long relationship or changing job. I am talking about that situation where you work on a problem for so long you don’t see a way out. We have all been there.

As developers, our entire career is about solving problems. As our experience grows we become better and faster at solving them. You start to get to a point where you feel like nothing can stop you. Then every once in a while you hit a problem. A configuration that doesn’t work, code that you just can’t get to compile or a query that returns wrong data.

Through experience, I have found the best thing is to walk away from that problem and come back to it. The longer you sit and focus on it, trying any solution Google has to offer, your brain gets agitated. The more agitated you get the more frustrated you get. Your frustration changes and clouds your thinking. The alternative to walking away is to talk to someone about it sooner rather than later.

A member of my team expressed feelings of anxiety and worry this week to me over being stuck on a deployment issue. They had been trying to get a deployment to work on a cloud provider we do not normally use. They had spent a few days on the issue not getting anywhere and requested some help. The solution doesn’t matter here. What concerned me was that they told me they felt they were failing in their job by not solving it on their own. That my opinion of them would be reduced and that people might even start to discuss them in a negative light. None of these points was valid. No one else even probably knew what that developer was working on for starters. No one else would probably have been able to solve the issue anyway. These feelings all stemmed from the frustration of spending 5 days trying to solve the issue. This had reduced their feelings about their skills and the way they felt perceived by others.

The problem is actually worse for remote developers who work on their own. They have no one on had to recognise they are struggling or who they could talk to. And that is the key solution to most problems. I picked up on the issue through our stand up process (Slack-based rather than physical). Sometimes it’s not a someone that can help it can be a something.

A suggestion in the Pragmatic Programmer book is to use Rubber Duck debugging in situations like this. This idea comes from the story of a developer who would carry a Rubber Duck around. When that developer got stuck they would sit and describe, line by line, the code to the duck. Often the act of describing it would allow that developer to discover the issue and solve it. This can often be the best way to solve an issue whether using a rubber duck or not. Talk someone else through the issue. I am not insulting my wife when I say that I have described problems to her in detail. She has no (or little) idea about what I am saying. It is the act of describing the issue that lets your brain offload, focus and process.

Next time you are stumped I suggest you try either method.

If you would like to discuss this topic further then please message me via twitter or email.

Google Duplex

Robot

Photo: Unsplash

Google unveiled Duplex today, an AI-based system for conducting natural conversations. Showcased at their annual IO conference, the demo caused quite a divided opinion.

Here is a sample of it booking a hair appointment.


It as caused quite an outpouring of opinion especially from people that believe it to be too creepy. They seem fine with synthetic Google Assist style voices but not a realistic human voice. They do not like the added imperfections and phrasing that humans produce when in conversation. A lot of the articles that are against the technology argue that as it would be hard to distinguish the voice from a human

This seems to be at odds with the excitement every time Boston Robotics release another video. Their Atlas robot is now doing backflips. Something distinctly human and unimaginable even a few years ago.


I guess people warm to the robots as they can see that it is a robot. They are not attempting to make the robot look human and so we do not feel threatened. But, what is not lost on me is how few people realise how advanced things have got. Boston Robotics released a video showing their dog like robot calling a friend to open a door. A lot of people laugh along without realising they are watching advanced AI in action. What would happen if that went bad?

This is actually the point that I think differentiates the Boston Robotic robots from Duplex. People can see the robots and perceive no threat. Duplex calling you up has no visual element. They are dealing with the unknown.

Still, it must surely be the aim of some to create the most human-like robot with the AI and voice of a human. This is the direction that technology has been pushing for the last few decades. What happens then? How would the human race react to indistinguishable robots? Are the likes of Elon Musk and Sam Altman right to warn of the consequences?

I’d love to hear your thoughts on this subject so please share them with me via twitter or email.

Git Commit Message Etiquette

Man Looking At Programming Code On Screen

Photo: Unsplash

Git has now been a de facto tool for developers. It has powered the awesome adoption of OSS and was the second well-known project from Linus Torvalds.

One of the things I look out for when looking at a projects repo is the standard of the git commit messages. It can sometimes tell you a lot about the developer(s) and the culture of the project.

It is easy to not give a great deal or thought to the commit messages you add to commit your code. This is especially true when committing in a high frequency as highlighted in the xkcd cartoon:

Xkcd Git Commit Comic

Now while your code should be self-documenting, your git commit log should explain what was done and when. It can be used to provide context to the commits and should be read like a history book of your project.

But, sometimes in the real world, we don’t care enough or are in a rush. Commit messages such as the following (taken from a project I am involved in) offer no value:

Examples Of Bad Git Commits

If we take the first log entry, I have so many questions. What method? Why are we now returning an empty list? What was returned before? That line was all that was included in the commit message. There was no extra content providing any insight. In order for me to see what was done, I need to diff the change. That takes time and I will still not be any wiser on why it was done.

I am not going to rehash how to write awesome commit messages or why it is important. Chris Beams has written the only article needed on it and I try to follow his recommendations.

Examples Of Good Git Commits


Examples Of Good Git Commit Message

The impact is your git log becomes a useful resource. This is even more important when your project grows or people move on. Knowledge is power and as developers, we need to know why things may have been done in a certain way. Git log should be your answers.

Let’s make a point of cleaning up our commit messages and calling out people that leave bad ones. Yes commit 227b4e11ae0824cc3a6508a990d99b4dbbed8f11 in the dotnet core repo, I am talking about you!

I’d love to hear your thoughts on this subject so please share them with me via twitter or email.

Amendment - Updated the example bad dotnet core example as when I saw it I thought back to this article.

Date.parse() With Server Side Strings

JavaScript Code In Editor

Photo: Unsplash

JavaScript date and time parsing is harder than it should be. This is especially true when parsing strings returned from server-side calls. The main problem at present is the fact that Date.parse() is implementation dependent. This means that what works in Chrome will fail spectacularly in all other browsers.

The simplest way to ensure that it works as you expect is to return your strings in ISO 8601 compliant format such as:

"yyyy-MM-dd"

or

"yyyy-MM-ddThh:mm:ss"

This will parse a date or a date and a time correctly. All times are treated as UTC. The topic of time zones and offsets is beyond the scope of this simple post. But, if you need to return a time with an offset then you want:

"yyyy-MM-ddThh:mm:ss +0300"

This will give you a Date object with the time set to 3 hours ahead of the specified time.

It’s funny how often date time string parsing confuses even experienced developers. If you need a thorough reference then the best I have found on this subject is here.

If you know of some good references on this subject or have any thoughts then please share them with me via twitter or email.

Meetings - Reduce The Frequency & Improve Their Value

People Passing Paper Of Meeting Table

Photo: Unsplash

Some initial thoughts on business meetings.

Meetings kill creativity and your team’s ability to function.

There I have said it. Meetings are the bain of many team’s life. Daily stand-ups, full team meetings and full company meetings. Then there are the meetings that need two-thirds of your team to talk about that one upcoming button change. Everyone has seen the jovial conference call videos such as below.


Meetings slow things down. The fact of the matter is that employees need time and uninterrupted time at that to work. Breaking up their day for needless meetings results in a break in their mental flow. Not only does it break their flow it also makes them context switch. For developers, the cost of a 15-minute meeting could be between 30 and 60 minutes for each participant. Preparation and context switching away from a task and back again after the meeting. That is a lot of wasted, unproductive, time.

I have tried to structure the meetings on my team and at Open Energy Market differently. First off, constant communication between the relevant people is preferred to meetings. When meetings are suggested, I ensure only the minimum relevant people are involved. In addition, make your team responsible enough to make a decision rather than needing it to be made by committee.

The current schedule is based on a constantly reviewed feedback.

Development team meetings

No daily stand up calls or physical meeting. Yes, I know, we must be the worst Agile team ever. How can we not have a daily stand up? We do just via slack. I have written about this before and it just works for a remote based team. Try it and see if it could work for you.

Backlog review meeting. This is the only whole team meeting we have every week. The whole devops team join to review the latest stories and tasks created by the product owner. We talk through the stories and estimate story points. It’s honest and sometimes brutal for the PO and we will push back on anything we feel cannot be worked on. It’s held at 9 am (UK time) on a Monday morning. This is to prevent breaking anyone’s flow. The meeting is time-boxed to 1 hour or 1 1/2 hours depending on the volume of items being reviewed.

Team retrospective. Held on a Tuesday first thing every other two weeks (we currently run two weekly sprints). The whole team come together to answer the 3 main questions:

  • What went well.
  • What didn’t go well.
  • What can we do better.

We tend to use a virtual whiteboard to help with this meeting and keep detailed notes. Actions are checked up on in subsequent meetings. This meeting is also timeboxed to an hour but usually lasts about 30 minutes.

Weekly catchups. I have an hour one to one with everyone on the team. They are scheduled at either first thing in the morning or last thing in the afternoon. This is to reduce context switching again. The aim of the catch ups is to ensure that each of my team gets time with me. They get to provide a detailed update on what they have achieved in the past week and details of any blockers. They also just get to present idea’s and if need be, rant.

Any meeting instigated outside of the Devops team is evaluated about its usefulness. We generally push back on these meetings but they are sometimes not optional. So we limit involvement to the only those people required. Most of the time I will take the meeting and feedback the results to those on the team that need to know.

Company Meetings.

This is a trickier subject. As an early stage startup, you absolutely need to have an all hand weekly meeting. For us, being remote, this was even more key. It helped to update everyone on progress, wins, loses and vital information.

When your team starts to grow these meeting get much longer. That risks devaluing the usefulness of them. We changed the structure of our weekly meetings when we hit this stage. We made it that each team gave an update on a weekly rotation. This was very useful and meant that they stayed around an hour. Again as the team grew it made the meetings quite long. Meetings have to add value and 90 minutes for 25 employees does not do that. It become a real issue when we had to hold it in the middle of the day. It was the only time that would overlap 3 time zones.

Right now we have dropped the weekly all-hands meeting. We are looking for alternative ways to share and communicate updates. Slack helps with this especially as we have integrated it with our platform. We all get notified about trades, new users and retentions.

We maintain a yearly “kick-off” meeting. It is used to get everyone together in the same room (or rugby stadium in our case). We hold that at the start of the company year to set targets and expectations on the team. It works really well and we always see great results in the following few months. We will be doing a mid-year one this year to maintain the traction.

This is what works for us. But, I would suggest while it might not work for you, you should review the meetings that consume your employees time and mental energy.

I’d love to hear about how you run your teams meetings so please share them with me via twitter or email.