Category: Ideas

Dec27201927 December 201927 December 20193Commentsby Gregor Suttie

Failure(s) and comfort zone

Posted in Ideas, Pro Tips

I wanted to cover some of the failures I have endured during the year. It’s not something you read a lot about from people and its important to talk about failure(s). I tend to mention my success’ but its also relevant to realise that there have been a number of failures in 2019.

I sat a number of Azure exams last year and failed on more than one occasion. I learned from this that no matter how much you study and put in you wont always have a successful outcome.

I wrote numerous blog posts which were sitting in my drafts folder for a long time which will never see the light of day.

I recorded umpteen videos which I never released and I still have them on my laptop, which again will never see the light of day.

I created PowerPoint presentations which yep you guessed it wont ever be used for talks.

I started numerous books and never finished a single book, was asked to review 3 or 4 books and again didn’t get the job done.

At times throughout the year I spread myself too thin and was trying to do too much, end result was the above.

Everyone has failure’s its part of becoming a better version of you.

As I reflect on this past 12 months its clear to me that failure is a good thing. Failure has taught me that each time I fail I learn something about myself which is key if you want to improve yourself.

Commitment
I have spent the last 2 years investing in myself, I commit myself to learning new skills and gain knowledge, with this comes failure, failure in my eyes means I am doing. It’s easy to say you want to do this or that but if your not actively doing something about it then it wont ever become a reality.

I have never given up after failing an exam or throwing away a presentation or a video, I use it to motivate myself to do better then next time, I keep the content as reminders.

The trick for me is to have goals, I write my goals on a piece of paper and have that pinned above my computer monitors on the wall. Last year I failed in only one goal and then this year I knocked it out the park, I kept the paper there until I had achieved that goal and now its been replaced with a new set of goals.

Stop holding yourself back
I stopped holding myself back, I used to think I’d love to do x or do y but I never truly thought I had anything to offer.
I spoke to some people at conferences who weren’t blogging but were right into tech and I suggested they should start, I wanted to say stop holding yourself back and just do it, they know they’re stuff and weren’t sure why they hadn’t been blogging.

I watched people speak at user groups and conferences and I thought wow I’d love to do that, I did nothing about it, I was holding myself back, scared I would make a fool of myself, I might still, but I am going to be going after it and see where it takes me.

Everyone has failures, you don’t hear about them, stop holding yourself back if that’s you, if your not failing regularly then perhaps your still in your comfort zone.


Tags:

Feb27201627 February 201627 February 20161Commentby Gregor Suttie

My company’s 2 day hackathon

Posted in Events, Ideas, Productivity, Training

Last week at work we did an offsite hackathon over 2 days offsite at Skillsmatter which is in Central London, the idea was to get offsite and brainstorm ideas around how we can benefit our users and add more value to the product we work on.

The hackathon included everyone from the team including UX designers, QA testers, Developers and Product Owners, and we had a clear vision which was our goal for the 2 days.

I had never been to a hackathon or anything like it before and I wont go into too much detail but the following is what we did for 2 days, how we went about it and perhaps you can take some ideas from it and do your own similar thing at your company or with your team.

hackathon

Ground Rules

Define some grounds rules at the start and try to respect them over the 2 days.

Day 1

  • No electronics allowed (i.e. mobiles or Ipad’s), except your laptop.
  • No ideas are silly.
  • Only one person speaks at anytime.
  • Elmos – Enough Lets Move On (if one person talks for too long).
  • HiPPO (highest paid person’s opinion, highest paid person in the office) – everyone’s opinion has same value and weight, bosses don’t make the decisions.
  • Parking Lot – area where some ideas aren’t thrown out but places on this part of the whiteboard for later on future discussions perhaps.

After we set some ground rules we split into teams and individually wrote down all of our ideas for ways to try to meet our vision and then we discussed and grouped them into similar types. From there we decided we had 3 ideas which we then whittled down to 2, we split into teams and started with some sprint planning in each team.

After we planned out our ideas we then started work using small 1.5 hour sprints, each sprint ending with a sprint retrospective and show and tell to the other team, here we gave feedback to the other team and discussed the good and the bad and the potential with each idea etc.

Day 1 lasted from 8:30 am to around about 6pm I think it was and it was a pretty long day but super awesome fun.

Day 2

Day 2 started again with some sprint planning, figuring out what we wanted to achieve and splitting out tasks for each person in the team to have something to work on and something to produce at the end of the sprint. Some people worked on the UI design, developers worked on the code, testers wrote some test and wire frames were also created by the Product Owners and some of the designers too.

I’ll skip to the most important part of the 2 days and what I personally took away from the 2 day workshop/hackathon.

What did we produce

After the 2 days we came away with 2 separate pieces of work which met our vision and will definitely improve our product, we had working code, it was tested, it looked pretty good and with a couple of days work would be production ready.

Lessons Learnt

  • Working in a different way to our normal 2 week sprints was awesome, having everyone in the team, all together, working around a table, throwing ideas out, dismissing some and getting instant feedback resulted in rapid feature creation from start to finish, in 1.5 days of actually doing the work we had something not far off production ready.
  • Instant Feedback – Feedback from everyone right there and then was key to delivering something we all thought worked, and would benefit our end users.
  • Every single person had a voice, every single person had their own ideas and collaborating together to pull the best parts of these ideas together was something which we don’t always get to do.
  • Offsite – being away from work and not having the disruptions of email/meetings/phonecall’s in a nice big building with areas to go eat and relax for a bit helped a lot.
  • Writing down all the ideas, being able to group them together and see the most popular ideas helped drive the towards picking the ideas to work on.
  • Being able to have everyone at the same level and not have the boss have the final say was quite an interesting take on it and one which I think everyone welcomed.
  • This will hopefully change the way we do larger pieces of work going forward in our sprints, getting everyone together and brain storming ideas, designs and getting instant feedback and rapid development so that we can take a piece of work and deliver more over 1 sprint rather than breaking the same piece of work over say 2 sprints.

Summary
I’d recommend your team try something like this, keep it organised, keep it simple, everyone is equal in the room, set ground rules, have a vision or a goal your all attempting to try to reach and have fun, the best part of the 2 days it was fun, we were discussing it all week afterwards and every single person loved it.

We covered a lot more than this but I don’t want to bore people with all the details – if you want to ask me anything about this post add a comment.

Thanks
Gregor


Tags:

Jan19201619 January 201619 January 20167Commentsby Gregor Suttie

Tips for Deploying your .Net project

Posted in Best Practices, Ideas, Octopus Deploy, PowerShell, Pro Tips, Productivity, TeamCity

Over the last 20 years I’ve seen many a deployment, some good, some bad and the ugly, life’s too short for manual/long deployments.

Here is what I recommend

If you have manual steps in your deployments then stop it, now, no seriously, you can deploy with zero manual steps (clicking deploy doesn’t count).

What to do instead

Get yourself TeamCity, yes TeamCity, Jenkins is ok but you get what you pay for, trust me Jenkins isn’t TeamCity. Ok now that you have an excellent build server, you’ll want to script your builds, for this I liked using psake along with PowerShell, honestly people who don’t know PowerShell are missing out, its awesome.

So get your scripts together and kick the builds off from TeamCity using psake.

Unit Test your PowerShell Scripts

Using Pester you can unit test your PowerShell scripts, thus realising that their fragile or poorly written or just large function which are hard to test, well do yourself a favour and use pester to unit test them.
Pester also gives you code coverage for your PowerShell scripts

Deploy your app

To deploy any .Net app use Octopus Deploy, its easy, its painless, it deploys with error handling, rollback using transactions, and you can do blue/green deployments, if you want to deploy a previous release, one click, deploy to multiple environments, any previous version etc. all in one click.

Summary
To summarise, no more manual steps, no copying files, manually unzipping files, creating folders etc, – no need to do that, and leads to human error, highly recommend each of those tools.


Jan0920169 January 20169 January 20161Commentby Gregor Suttie

Liquidity matrix – what is it and how might it help your team?

Posted in Ideas

Over the years I’ve seen a number of places of work which suffer from the following, a team member leaves or is on holiday and he or she is the go to developer, the developer that’s the only person who really knows that topic or area and as a result you have to wait for them to return, lets face it I’m pretty sure this has happened to a huge percentage of us, so here is an idea to help with this:-

So for example say we take the following as an example:-

lmatrix

From the above we can figure out that Andy doesn’t know anything about the internal and external websites, perhaps he can be brought up to speed, also Andy is the only person who knows anything about the Deployment and the PowerShell scripts, that means he’s the bottleneck or however you want to put it, other developers should be brought up to speed so that he is not the only person with knowledge in that area, if he went on holiday or left then you have a glaring problem.

You can do this same will skills and this is much more common I have found, and yeah not everyone is keen to admit to not knowing much about a certain area but just reassure them that this is not what this matrix is for.

Maybe some of you will find this useful, hopefully it doesn’t show that your team rely on some people, and its good to share knowledge within your teams.