Acquiring Skills and the Prism of Belief

Leave a reply

A very short point about learning, skill acquisition and mastery.

Having NOT been through the Comp-Sci degree -> Junior Developer -> DevOps Engineer route I have often struggled with the seeming inexhaustible depth of other people’s knowledge around things like networking, object orientation or other ‘hard-won-experience’ type topics.

Sadly my impression was that some people were just “better than me” at being a developer and I would always struggle.

I did however posses just enough good sense, having left a very comfortable position where I had a ridiculous amount of tenure, to realise that this underlying perception wasn’t helping me at all.

I had moments of regret about leaving such a comfortable position where I had ridiculous amounts of tenure, swapping that out for a huge challenge. This became especially problematic when my memory of previous frustrations started to fade. Clearly this way of viewing the world had to change, otherwise I wasn’t going to be enjoying work very much.

Luckily your world and your experiences in it are a reflection of the every-day thoughts you have about yourself and how things are likely to transpire. If you spend time amplifying the negative and stressful aspects of what you are doing it’s going to be quite challenging to enjoy things.

Conversely if you see difficulties as opportunities to grow and you focus on the present moment when thinking about what is going on then at least you’ve got half a chance to approach any given topic with an open and expansive view.

Whether you’re an optimist or pessimist, you’re likely to be correct.

Talking to other, more experienced, developers about their struggles and history you find out that even those with 10-20 years experience feel that they’re always learning and they often experience that uncomfortable situation where they don’t exactly know how to do something. The difference being that they’ve got multiple years or experience and built up intuition about how something ‘might’ have gone wrong or where.

A quick example… Looking at how to define an address for an s3 bucket the variable was written /s3-iigpoddkhfldfhds which when it was used in the API call to define where to look it resulted in https:///s3-iigpoddkhfldfhds buried in the debug output. Now, this wouldn’t have even stood out had I been looking at this two years ago but I looked at that and at least thought “hmmmm… that’s a bit odd”.

You argue one of the differences between a beginner and an expert (apart from the ‘skills’ part) as having a larger tool kit of experience which enables them to hone in on a solution to a problem or to dismiss unlikely solutions. The difference is analogous to having a full automotive socket set or just a hammer.

Your own belief’s come to the fore in areas like acquiring new skills, sitting for certification exams or when examining your feelings about whether you’re adding value or not. If you are unable to accept that how you believe about a thing directly influences your results then, as an experiment stop thinking nice things about your partner and focus on all the things that annoy you about them, good luck! Things will quickly go south. Conversely the opposite is absolutely true.

I can’t pinpoint exactly how and when the switch over from feeling under-pressure and stressed to enjoying the challenges happened BUT here are a few of the key realisations I had along the way.

  1. It’s actually supposed to be hard. In the most fundamental sense, if all these topics were easy then we wouldn’t be in the enviable position of being able to (mostly) work from home and be paid as highly as we are. Recognising that this isn’t a simple set of skills to just harvest from the ground will encourage you to keep going when it doesn’t just magically fall into place.
  2. You are vastly better at this than you were 6-18 months ago, so keep going. Not only will you improve technically but you’ll improve emotionally. You will have more resilience when it comes to setbacks and be able to recognise that 99% of the time you are able to figure it out.
  3. I developed a learning plan which focussed on being specific about what I was going to tackle each week. This consists of technical topics outside of what I might be trying to do in my normal job as a way of avoiding burn-out. There’s no pressure there but these are also things I’m interested in learning for their own sake or for some future endeavour.
  4. I stopped comparing myself (technically) to others. This is a pretty hard thing to do but you need to recognise this isn’t a winning strategy. Yes, be inspired but don’t take it to heart. It’s a journey.

To tie this all back to belief, which is (imho) fundamental… If you look outwards and recognise that it may be a challenge but it’s ultimately all do-able then you’re going to have a far better chance of succeeding than if you let yourself be crushed by un-realistic expectations and negativity. Record your wins, talk to those around you, be intentional about what you’re trying to learn and above all be open and talk yourself though challenges. It will get easier eventually and at least this way you’ll enjoy the journey far more.

Expectation Management for Engineers

Leave a reply

Here are three things you should try to be aware of as an engineer who has deadlines.

If you’re able to manage the expectations of those around you then you’ll experience less stress.

1. The person asking the questions has the initiative

Remember all those movie scenes where the detective shouts “I’m asking the questions here!”. There’s a reason that they do that. They’re trying to control the conversation.

What does this mean for you as an engineer? If you’re continually waiting for your manager(s) or colleagues to come and ask you about the progress of something then you have relinquished control of the narrative.

If someone asks you a question then you are already on the back foot but how any question is asked (which you’ve got no control over) also plays a huge part in the subsequent direction of any discussion.

Practice giving short concise updates to managers and team-mates before they ask.

You’ll be more relaxed, you’ll get to understand more about what information various parties need about what you’re doing and you can engage in a dialogue about the work.

You’ll be seen as someone who is in charge of their piece of the endeavour.

2. Don’t disappoint a toddler

If you think of people you’re delivering to as toddlers, you can’t go far wrong. Obviously all your colleagues and managers are enlightened, empathetic people who have undergone some personal growth and leadership training…

At the same time, no-one likes to feel disappointment. If you’ve previously promised a toddler that if they only wait till after dinner they can have a lolipop and then don’t allow them to have one, you should expect a huge meltdown.

Similarly if you’ve spent two weeks on a feature but the day before are forced to tell the person waiting for it that it’ll be further delayed what you’ve effectively done is triggered that emotion within them.

There are so many ways this can be avoided:

  • Get ahead of the problem by starting a dialogue about potential issues as soon as you get an incling that there may be some challenges to overcome.
  • Talk about the key aspect of what is being developed. Does it all need to be available to get 60% of the functionality? Can it be broken down in some way? Something is better than nothing in nearly all cases. Maybe enough of the feature can be delivered on time?
  • At the very least, you coming forward early allows whoever is downstream to manage the toddler in their life.

No-one likes a toddler shouting at them

3. Surface your work

Technically this isn’t expectation management but if you’re able to do this in a straighforward and direct way you will reap the benefits as more freedom. At the very least you’ll start to gain some leeway and breathing room when it comes to your day-to-day work.

It is important that you know what you are working on and have basic time management skills.

It’s even more important that your team/colleagues and managers know what you’re working on, how it fits into the overall goals of the business and why it is valuable.

You should never assume that because something is important to you it is important to everyone around you. You know what you’re doing and why but others won’t.

Yes, it may well be a great improvement to the automation framework which will reduce the mean time to restore service to 5 minutes from an hour but if you never put this in front of your co-workers all your greatest work will fly under the radar.

Just by saying “hey, come look at this, it’s cool” you’ll have people standing behind you when times are tough… and in the meantime you’ll have space to create.

I hope you found value in these points! 😀

Remote working will no longer be special

Leave a reply

Some changes, once they happen in a society, can’t be undone. Remote working will become a great example of this.

In dark times people cling to the tiny rays of sunshine which poke through the continually depressing news cycle. For many, remote working has been a rare source of joy.

I have found “remote” working or “working from home” to be as entirely excellent as I’d suspected it might be and I’m sure I’m not alone in believing that there’s going to be an almighty scene should companies attempt to herd their staff back into offices.

Any and all reasons why a company shouldn’t allow their staff to continue to work remotely have now been disproved. If companies insist that we should all, en-masse, resume commuting and sitting in one big room this suggestion should be treated with the skepticism it deserves.

Having been fortunate enough to work from home since the start of the pandemic I’ve been able to:

  • Save money and time commuting
  • Move further away from the office to where rent is cheaper
    • I actually bought a boat to live on but that’s a different post!
  • Enjoy spending more time with my partner
  • Eat a lot healthier
  • Have long, uninterrupted periods of time for writing code
  • Think deeply about how to address some complex business challenges
  • Reflect on my own career trajectory and make some changes

Getting back an hour per day (the commute) and having the opportunity to work in an environment that suits me seems to be the way forwards.

Of course there are some people who sincerely believe that communication is better when everyone is sitting next to each other in a big room. That somehow the air becomes magical and filled with ideas bouncing off each other so we’re all unknowingly propelled in the same direction.

This theory is great if you want to run your business based on some sort of miasma which relies on chance and happenstance to get anything done. It just doesn’t come across as a winning formula to me…

There are challenges to overcome with remote working and those in favour of office based work wheel them out as proof that somehow remote working is not as effective.

What people fail to realize is that these challenges are actually the beneficial constraints which result in the creation of a functional, process driven business where everyone is informed as to the overall goals and values of the company.

Let me see if I can make this clear…

Communication and Processes

These things now have to become intentional, in other words Managers have to communicate a vision, reward the behavior they want to see, promote the values they want the group to embrace and provide actionable answers to questions.

Good managers do this anyway but for a remote team this becomes even more important to avoid everyone deciding for themselves what the goals are and how their work contributes to moving the business forwards.

Written communication is key here and shooting from the hip doesn’t work. All the questions employees might have about getting something done should be ultimately linked back to the values espoused and (often) repeated by senior team members. Those are guiding principles which don’t require micro-management.

Similarly, all businesses should be process driven and those that aren’t will seriously suffer when remote staff don’t know the protocol for getting something done.

Processes also need to be written down, they need to be linked to a measurable outcome and they obviously need to make sense. Having processes (documentation) with steps to follow means someone has had to think clearly about the whats and whys of something. In many cases that alone results in the process being improved because time has been taken to look at what’s involved.

Hiring and On-boarding

Following on from communication and general business processes, hiring and on-boarding also benefit from the rigors of having to conduct these activities without face-to-face interaction.

This encourages thinking deeply about what new job roles actually are, what is needed, how to evaluate candidates in a non-biased way and what constitutes a sensible interview question.

Then you need an on-boarding process which doesn’t rely on being able to prod the old hand beside you and ask questions, the answers to which haven’t ever been written down, just passed like holy tablets…

Finally career planning/mentor-ship and progress reviews need to be actually scheduled rather than consigned to a mythical future time when “we’re all less busy…”

Tracking work progress

A great concern (especially for Managers) is that they won’t be able to “see” people working. Great! Now is the perfect opportunity to embrace some form of tracking/task management tool to surface all of that work going on, whether it is in the form of completed actions or software artifacts, just have something!!

A cynic might argue that some managers are in fact averse to taking advantage of the structure task tracking tools provide as they highlight how little work is involved in actually, well… managing…

However, we’re not in this camp so the positives here are that task tracking tools (Jira, Trello etc.) are an amazing way to measure progress, to “surface” work being done and to share progress towards a much larger goal.

There’s almost nothing as depressing as hearing that “big bang project x is still being worked on” alongside the refrain of “it’ll be done when it’s done” when the alternative is actually knowing that about 50% of the tasks to reach the ultimate goal are actually completed.

Those who can’t track progress towards a goal have no hope of reaching it and since expectation management is the core of project management not knowing where you are (even vaguely) along a continuum of tasks works against this.

Remotely distributed working and customers

When it comes to customer engagements (delivering some feature or service) it seems that > 90% of the interaction with them is actually carried out remotely. Clearly the days of the traveling salesman and even the much hallowed “customer visit” are largely over.

Businesses no longer buy via a “vendor relationship” where influence is top down. If it’s not a committee of approvers most B2B sales are now driven by free trials, POCs and internet searches for solutions to a specific problem. No need to meet a salesperson or any sort of technical installation team at all.

If your sales process or customer interactions need to be carried out remotely, why do we believe that our internal communications have to happen in an office? Surely, if our most important business transaction (selling to customers) needed the highest chance of success, by current management logic all sales would be face-to-face as this is apparently “better” than working in a distributed way… The logic doesn’t stack up

Information passing and openness

Each time information has to cross a boundary effort has to be expended. Whether it is asking someone to do something, tracking activity for a certain project, getting the status of something, the information has to be passed from one entity (group or person) to another.

Now, with Covid, all information has to pass explicitly to someone or come from elsewhere. Office based happenstance just doesn’t happen so this requires openness and honesty from all parties as to the status of each activity.

Employees who recognise this are in a great position to benefit because they have chosen to take ownership of the quality, content and trajectory of the information they give out. They are pro-active in their supplying of valuable information to the rest of the business.

People who require others to chase them all the time are relatively less valued because chasing around after someone to find the status of a particular thing is just annoying because it requires expending energy.

This is why it’s always annoying trying to find anything on a company intranet.

Summing up

Successful remote first companies can talk endlessly about why this approach is better but I think the “remote” aspect is the icing on the cake, not the cake itself.

Business success relies on execution in an explicit, intentional way. It requires written processes, depth of thought when it comes to execution (programming, sales, marketing etc.) and a communicable vision. Without these attributes any business will suffer, remote or not.

Relying on some mythical “communication miasma” permeating offices is foolishness when people’s personal incentives don’t support this idea, let alone all the science which contradicts the statement that “people communicate better” when working in an office.

A distributed company is naturally more resilient and if it wants to succeed, has already undergone the pain of answering all the questions it needs to about how it fulfills its purpose.

Dragging everyone back into the office based past is foolishness, especially as the world has now proven that remote work… works.

Did you get my email?

Leave a reply

Firstly, imagine the sort of cinematic pyre usually reserved for the final ‘baddie’ in movies. Now, visualize shoving all your email into it. Great or what?!

There are so many issues with companies reliance on email but I’ll put a few out there…

  • Encourages silos within the business
  • Encourages political game playing
  • People may not have equal access to the information they need in real time or historically
  • Email overload means many people don’t respond to your messages
  • Often used in place of a call/meeting where a conversation would last minutes at most
  • Encourages the deferring of issues or passing them around rather than resolving them
  • Ridiculously hard to refer back to/search in to find historical information
  • Encourages a reliance on file/attachments which then get lost – usually breaks any sort of documentation version control
  • Messages are often miss-interpreted by the receiver
  • Usually the message is without necessary context to enable the recipient to actually make a decision

Now I completely understand that people are very used to email however it’s a legacy of the business processes we used. All it is is an electronic memo.

I’m sure the same stupid ‘did you get my memo?’ games were played then and all email does is perpetuate the same silo organisational structure.

We’ve got access to excellent project management, scheduling, knowledge base and workflow tools that mean everyone can get/see/ and most importantly share the information in an open forum.

We began using Slack at work – it’s amazeballs because it fosters far more open communication among team members and across teams.

In a modern business where people have to collaborate then almost everything should be open and accessible internally. Email works against this goal.

Expediency

Leave a reply

I’ve had a blog (on a totally different subject) for ages. It was hosted on WordPress but no longer reflected who I am now or my interests. It was old but letting go of it was hard.

I had another site/blog which contained some more recent ideas but it was not polished and while looking at Go I ran into Hugo. It’s a static site generator written in Go. It’s lovely.

I wanted to start putting my professional thoughts out there ’cause I’ve really grown to enjoy the whole process of software development. I’m not yet very good at the technical parts but since there’s a lot of human communication and so-on involved the challenges are really interesting.

I got hung up on the yak shaving required to actually build/restructure and deploy my blog using Hugo. It was in the back of my mind but was easy to put off. I fell into the trap whereby I’d decided how I wanted to do something (using Go and Hugo) while forgetting the actual goal was to put my stance on a couple of things out into the world.

This can happen when writing or fulfilling user stories too. You can dive straight into the implementation detail and ignore the over-arching goal which may mean you don’t have to really write much code at all. Maybe the end result could be achieved with fewer steps?

There’s a temptation to be restrictive and provide detailed guidance as to how something should be achieved. The underlying problem here is that this approach robs people of agency over how to reach a solution. If you’ve been told exactly how to do something there’s no ownership as you’re just following someone else’s plan. If it happens to fail then the easy out is to point out that it wasn’t your plan therefore you’re not to blame.

It finally hit me. My underlying goal was to remove my old content and replace it with something more relevant to me at this point in time. The what has been achieved by expediently sacrificing the how. I didn’t (yet) port the blog to Hugo but the end result I wanted has been achieved.

Users mainly care about what happens, not how.