The online slot machine market is rapidly expanding, with iGaming spreading across the world.

2020 was not a great year for many things, but for the world of online casinos, it presented a wonderful opportunity. More people were forced to sit at home looking for alternative pastimes, often turning to their mobile devices to find solace and escapism. That brought a huge number of new customers to the industry, with revenue expected to grow to $114.2bn (kn713.3bn).

That presents an opportunity for developers and coders because each of the games that feature on these sites needs somebody to create them. The world of online slot machines is a competitive one, and not only do they tend to function on similar technology, but they also need to boast impressive graphics and sound to appeal to a generation of gamers used to bright colours and immersive experiences. Often, these providers use bold imagery to help their product stand out from the crowd, and that dictates that behind the spinning wheels there must be skilled individuals building and designing experiences. Leading European slot provider Foxy Bingo have lots of titles that use strong branding and imagery to set a scene for the player to enjoy, such as The Perfect Heist and Neon Pyramid games. These games have clear design aesthetics that make them stand out, as well as being more about the overall experience, rather than a simple slot machine. When you consider this must then function on both Android and iOS, the world is your oyster if you have the right skills.

What technology lies behind these games, and what may permeate into the industry in the future? These are the core principles, mechanics and growth fields to consider.

RNG

Almost all casino games, online slots included, use a random number generator to determine whether a player wins or loses. Assuming each reel of a slot has ten possible outcomes, a random number generator will create a random outcome for each, either wheel by wheel or a single number that determines the outcome. All online slots use this function, and it does mean the outcomes are completely random.

3D Modelling

When many people think of a slot machine, they might picture the old one-armed bandit’, with cherries and melons spinning around. Online slots are nothing like that and the very modern ones use 3D modelling and illustration to create the user experience. Creating a slot is not a one-person job, and an illustrator and designer can be drafted in to work exclusively on the design and characters without ever having to worry about RNGs.

Mobile Conversion

Online slots originated on the internet, programmed for PC using something like JavaScript or Flash Player. Increasingly, players now want the experience on a mobile device, be it Android or iOS. Therefore, anyone with the skills to make the port happen, or even create an identical game from scratch on a mobile device, will be in high demand. Gamers want consistency, so if they find a slot they like at home on their computer, they will want the same experience from that game on their tablet, or whilst commuting on the bus using their phone. With devices running at 1080p just as they do on PC and capable of handling 3D graphics, mobile conversion is a whole new aspect to online slots that grows daily.

VR and AR

Virtual reality and augmented reality are not common within the online slot sector right now, but they will be. Both areas of design and tech have scope for creating even more immersive and enjoyable experiences for the player, keeping them coming back. Customer retention is key and with so many providers on the market, innovation is likely to be a key strength of a successful provider going forward. AR could allow you to build your surroundings into a game, so the player spun the slots using their kitchen fridge as a backdrop, whilst VR could recreate a whole casino experience without ever having to leave the house. That is exciting for players but mouth-watering from a developer’s point of view.

Here are my highlights from a highly recommended book The Manager’s Path by Camille Fournier.

Management 101

• 1on1 meetings with your direct manager are an essential feature of a good working relationship.
• The bedrock of strong teams is human connection, which leads to trust. And trust, real trust, requires the ability and willingness to be vulnerable in front of each other.
• Good managers know that delivering feedback quickly is more valuable than waiting for a convenient time to say something.
• Bring agendas to your 1on1s when you have things you need to talk about.
• When you want to raise, ask for it. When you want the promotion, find out what you need to do to get it. Your manager cannot force work-life balance on you. On the flip side, sometimes if you want a bigger job, you will have to work more hours to get it.

Mentoring

• Listening is the first and most basic skill of managing people.
• Mentoring new hires is critical. Mentoring an intern: give them a project and make them present the work.
• Alpha geek tries to create a culture of excellence but ends up creating a culture of fear. If you’re ever in a position to promote people to management, be very, very careful in giving your alpha geeks team management positions, and keep a close eye on the impact they have in that role.

Tech Lead

• The idea that the tech lead role should automatically be given to the most experienced engineer, the one who can handle the most complex features or who writes the best coach, is a common misconception that even experienced managers fall for.
• Tech lead is a leader, responsible for a software development team, who spends at least 30% of their time writing code with the team.
• I have a strong opinion on pushing people into management, which is that you shouldn’t do it.
• Real-life of a manager: when you only had a team you were able to balance things and still write code, but as your team has grown you’ve lost touch with the code. It’s troubling you as something you should be doing, but there’s no time.
• Successful leaders write well, they read carefully, and they can get up in front of a group and speak. Don’t forget to listen during all of this communication.

Managing people

• It’s hard to accept that “new manager” is an entry-level job with no seniority on any front, but that’s the best mindset with which to start leading.
• Regular 1on1s are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time. The default scheduling for one on ones is weekly.
• Some people assume that good relationships require very little attention, and spend all their time on their bad relationships.
• As much as possible, when someone does something that needs immediate correct feedback, don’t wait for the 1on1 to provide that feedback. The same goes for praise!
• When you strip creative intelligent people of their autonomy, they lose motivation very quickly.
• The worst micromanagers are those who constantly ask for the information they could easily get themselves.

Managing a team

• Leaders are capable of identifying the highest value projects and keeping their team focused on this project. In addition to focusing the team, they are capable of identifying headcount needs for the team and planning and recruiting to fill these needs.
• If you truly wish to command the respect of an engineering team they must see you as technically credible. You need to stay enough in the code to see where the bottlenecks in-process problems are. It’s hard to make up lost time when you stop writing code, and if you do it too early in your career, you may never achieve sufficient technical savvy to get beyond the role of middle management.
• Infrequent releases can hide the pain points such as poor tooling around releases, heavily manual testing, features that are too big, or developers don’t know how to break the work down.
• Project management rules of thumb:
  • Do you have 10 productive engineering weeks per engineer per quarter
  • Budget 20% of the time for generic sustaining engineering work across-the-board
  • As you approach deadlines, it is your job to say no
• Test of happy engineering team: “If you buy them pizza in the evening, will they stick around and socialize together, or will they race out the door as quickly as possible?“
• Whenever asked for an estimate, take your guests and double it.

Managing Multiple Teams

• The engineering director
  • is responsible for a significant area of the technology team. Leads engineers across multiple product areas, or multiple technology functions. He is not generally expected to write the code on a day to day basis. However, the engineering director is responsible for the organization’s overall technical competence, guiding and growing that competence in the whole team as necessary through training and hiring.
  • should have a strong technical background and spend some of their time researching new technologies and staying abreast of trends in the tech industry.
  • focuses on ensuring that we continue refining our development/infrastructure standards and processes to create technology that will deliver sustained value to the business. They are leaders for recruiting, headcount management and planning, career growth, and training for the organization. They’re responsible for creating and growing the next generation of leadership and management talent in the organization, and helping the talent learn how to balance technical and people leadership and management.
  • is a motivated, cross-functional collaborator, a very strong communicator, and has a positive public presence.
  • should spend the time to gain mastery of programming before moving up to management.
  • spends at least a solid half-day once a week completely free from meetings or other obligations and uses this time on some creative pursuit (blog post, conference talk, open-source project).
• One example of an important but not urgent task is actually preparing for meetings so that you can guide them in a healthy way.
• Engineers who don’t write tests often have a harder time breaking down their work.
• Frequency of changes is one of the leading indicators of a healthy engineering team.

Managing managers

• You must take the time to proactively hold skip-level meetings with the people who report to your direct reports (once a quarter).
• Learning how to hold managers accountable will be one of your biggest learning opportunities as you work at this level.
• A manager is accountable for the health and productivity of the team.
• Making the wrong person and manager is a mistake, but keeping her in that position once you’ve realized she’s wrong for it is a critical error.
• Don’t compromise on culture fit, especially when hiring managers. Many people are very reluctant to hire in management from outside, and for a good reason.
• Dedicate to 20% of your team schedule to “sustaining engineering”.

The big leagues

• It’s not about being the lead engineer, chasing the latest language or framework, or having the shiniest technology. It’s about building a team with the tools and attributes to build the best possible product for our customers.
• VP is an engineering role, CTO is not.
• In my experience, most people need to hear something at least three times before it really sinks in.
• As a senior-most person in an organization, you’ll be watched closer than you ever been watched in your life.

Bootstrapping culture

• Structure is how we scale, diversify, and take on more complex long-term tasks. It’s more common in small companies to see structure come too late.
• He describes the early start-up as driving a race car. You’re close to the ground, and you feel every move you make. You have control, you can turn quickly, you feel like things are moving fast. Of course, you’re also at the risk of crashing at any moment, but you only take yourself down if you do. As you grow, you graduate to a commercial flight. You’re farther from the ground, and more people’s lives depend on you, so you need to consider your movements more carefully, but you still feel in control and can turn the plane relatively quickly. Finally, you graduate to a spaceship, where you can’t make quick moves and the course is set long in advance, but you’re capable of going very far and taking tons of people along for the ride.
• A complex system that works is invariably found to have evolved from a simple system that worked. Complex system design from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
• Culture is how things get done, without people having to think about it.
• Call them what you want pods or squads or pillars, but cross-functional product development groups are a popular structure for a good reason. By putting everyone who is needed to make a project successful together in one group, you help the members of those teams focus on the project at hand, and you make the communication for the whole group much more if active.
• Organizations that design systems, are constrained to produce the designs which are copies of the communication structures of these organizations.
• The most important lesson I’ve learned is that you have to be able to manage yourself if you want to be good at managing others.

TL;DR

In this post, I’ll show you some pictures and notes from the very first .debug conference.

⚠️I know, I know, this post comes veeeery late after the conference was already finished 🤦, but I figured that this will (sadly) most probably be the only one I’ll attend the whole year, so I might as well share and recall how it was.

The Swag, oooh the Swag

I was impressed by the amount of stuff they put in the rucksack (oh yes, there was a rucksack too 😊). Yeah, sorry, the chocolate didn’t make it intact to the picture time 😛

I’ll now go through all the sessions that I attended, share a few pictures and notes.

A new World for Your App, Justyna Jaworska

• Basically talking about the ‘business opportunity’ to build stuff for this platform

10 types of devs you’ll meet at the conference, Dora Kalneus (Militaru)

• speakers, thought leaders, hipsters, influencers, nomads, entrepreneurs, consultants, blockchain something something 🙂, hackers, #iamdeveloper
• awesome presenter, great flow
• “Suffering unites people”
• Personal branding is about creating an opportunity for you to grow

Companies without designers are building a catastrophe, Tom Kozačinski

• “Just build it doesn’t work in big companies anymore”
• “Never hire on the lower end of the salary spectrum”
• “Rather than focus on artifacts, we focus on prototypes and validating those prototypes in Discovery, with the added benefit that the prototype serves as the spec for Delivery.

Panel discussion on how to get paid for your work and knowledge

• Luka Abrus
  • gap getting tighter for seniors
  • Agreed that people once coming from the college have to have projects behind them
  • Government is not helping at all
• Alan Sumina
  • Our tax system is like Swiss cheese and they weren’t prepared for ‘pausalni’
• Tatjana Barančić
  • People stopped going to Ireland
  • We see a lot of developers coming back now
  • ‘Pausalci’ that work in a freelancer setup will have no problems
• Hrvoje Balen
  • We are stupid as people will just start companies outside of our country.
  • Lower the tax on work and increase on real estate (only 8%!?), as otherwise, we’re turning into a renting country

Devonomics – Expanding the developer horizons, Srdjan Vranac

• “Later equals never”
• “Never talk about technical debt” – 🤔🤦 oh, really?
• “Your mandate as a software engineer is to find solutions for the problems presented, with acceptable compromises between time, cost and quality, with buy-in from the management/leadership.”
• Time to market is the only metric – shorter TTM -> more money
• Everyone is a salesperson!

AI in banking, Draženko Kopljar

• “AI is a buzzword for sales people so they can sell stuff easier” 🙂

Panel discussion about ‘the life after coding’

• Mihaela Smadilo
  • It’s hard to make the switch to manager, and communication skills are the key
• Tomislav Grubisic
  • Regular 1on1 check-ins are key
• Luka Kladaric
  • Your knowledge evolves, so if you work on a new technology you’ll actually have it easier to learn new things
• Oleg
  • “Most CEOs are complaining that devs are bad”
  • Personally, I think that the panelist was pushing this question of “what are you gonna do at 60!?”, and they were trying to explain to him but with no luck. Even to, it seemed, a point of irritation.
• Sven
  • I think that the main motive nowadays is that people work on interesting things

From diploma to Google, Maja Bilic

• This was an awesome presentation, should have been the keynote yesterday
• Imposter syndrome is real
• The important thing is to like things that you do
• NTH sucked: on the third day became the design team lead, then the web team lead – I knew exactly nothing about this!
• Did a lot of retrospection and thinking what I want to do
• Got two jobs in Google – and then had to make a decision
• Putting things on the paper and weighing is bullshit as you always deep down have an actual decision you want to do
  • I make a decision, tell everyone, sleep on it. If I don’t regret it, then I actually execute on it.
• People need growth and challenge that’s out of their comfort zone
• Interview to realize what’s your value on the market
• I was so disappointed that there’s no ideal organization – but here’s your chance to bridge the gap
• A good manager will give you feedback on your performance but also tell you what you need to work on
• Change is what brings progress as that yields a lot of spaces that aren’t covered
• Titles don’t say anything about what you actually do
• Know something that no one else knows
  • Never say that’s not my job, and always know what you’re doing
• Ask for feedback
• Know when to move on: when there’s nothing that excites you
• Mentor – you have to click with this person to ask what to do at a certain problem point
• Good team, interesting job and opportunity to learn – money comes after this

10 mistakes I did as a young IT guy, Luka Abrus

• I thought that people will appreciate my code
• Vanity metrics
  • Today we’re actually celebrating when we see good metrics and not when we launch!
• I thought I knew what customers want
• I loved emails and didn’t wanna go and meet with people
• As an employer, I was slow to fire
• I thought that money was the most important
• I didn’t know how to make a good project deal
• I didn’t know when to say ‘go to hell’ to the client
• I applied to things I didn’t have the competency for

Experiments done in business and life, Martin Stenkilde

• “As long as you learn something from the failure, everything is great”

Tech Leadership: People + Technology, Kátia Nakamura

• Ooof, didn’t resonate with me
  • I totally disagree that someone **shouldn’t ask something in the public Slack channel
  • Does 1on1s every other month – come on, seriously?!
• Agree only on the last point that you have to have people that take care of other people, and the importance of (written) communication

Hairy Developer and the Sorcerer’s Startup, Shahyar Ghobadpour

• Great presenter!
• Learned how to be tough after they got evicted
• Office politics is real and it’s not always about how good you are
• Learn as much as you can anywhere you go
• Risk, but research beforehand
• Be good with people, time, skills – if you aren’t, then find a matching partner

Till next time, stay safe 🙏

TL;DR

In this post, I’ll share a few tips on how to set the goals, track them, and work towards completing them.

Fair warning: this may be a ‘too much’ kind of post, but it also may be very motivational. It’s your choice. You choose if you’ll think that this is an exaggeration or something that may give you an edge you need. Either way, remember why you’re getting into this: you’re here to get ahead and succeed, not to slack off or barely get by. So, buckle up, it’s supposed to be hard. Going an extra kilometer (miles are overrated) is easy – there’s truly not much competition down the line.

⚠️ All of the things I share here are the things that I do. The books I recommend are the ones I’ve read. However, this may, and then again, may not work for you. Though I’m pretty sure if you do half of the things from the list, you’ll be hooked by the unexpected surge of productivity that you’ll want to learn more, and in the end, find your own best set of tools/books/tips/systems.

If you’re here just for the tips, here they are:

• How to set them
• Write them down
• Set them for a year in advance
• Plan each day
• Do the work
• Prioritize the tasks
• Work on the one thing at a time
• Work on the most dreadful task first
• Use the Pomodoro technique
• Develop a routine

At the end of this, I also touch on Motivation and Remote work.

HOW TO SET THEM?

Here are a few short tips on how to set them.

Write them down

There’s some ‘magic’ in writing down what you truly want. Don’t question it, just do it, write your goals on a paper/notebook/wall 😉

One of the best (and shortest) books I’ve read on the topic of setting goals is Goals! by Brian Tracy.

There are also book summaries, and YouTube videos of this book in case you’re interested. I’d still recommend reading the book for more info on what format they need to be in, but one is this: be specific in what you want.

Set them for a year in advance

At the start of the year, set your yearly goals and then break them down to quarters, then down to months, weeks, and finally days.

If you’re starting out, quarterly will be fine. OKRs fall nicely into that.

Sometimes things go according to plan; sometimes they don’t. Review them (I do that every month) and adjust accordingly. However, do not!, delete them – you’ll use these at the end of the year when you do a full review of the whole year.

Some may say that you need to plan for 3, 5, or whatever number of years. That’s fine too. Find a number that works for you long term.

Plan each day

Yes, I’m serious when I say you should plan your days. I’ll even go further and say that you should plan each hour of your day. Plan when you work, plan when you play, plan when you relax. Plan to work in blocks of time.

Ideally, every night before you go to sleep, create a plan of your whole next day. The first thing in the morning is the second-best option.

Google calendar may help, but I still use a normal pen and paper. I like the Best Self journals.

Saturdays and Sundays should not be an exception. Again, remember the note from above: you’re here to succeed, not to slack off. They may not be your full ~~12~~ 8 hour workdays, but they can be ‘light reading’ days. But please, whatever you do, don’t turn them into Netflix binging days. If you do that on a consistent basis, you might as well stop reading this right now, as this will not resonate well with you.

DO THE WORK!

Here are a few tips on how to actually work towards completing them. These few tips will boost your productivity, only if you stick to them.

• Prioritize the tasks
  • > “If everything is important, then nothing is.” ~ Patrick M. Lencioni
  • Prioritize the tasks using the Eisenhower Box method.
• Work on one thing at a time
  • A good book on the topic is The One Thing by Gary Keller.
• Work on the most dreadful task first
  • A good book on the topic is Eat That Frog by Brian Tracy.
• Use the Pomodoro technique
  • You need a few minutes of reading this Wikipedia link to learn how to apply it.
  • I challenge you to do 8 ‘true’ Pomodoros a day. And when you do, I’ll be waiting for that thank you note about the newfound increased productivity that you got.
• Develop a routine
  • Start your day with a routine like life savers (from the book The Miracle Morning by Hal Elrod). The key thing is: adapt to your style and, more importantly, stick to it.

Motivation

Motivation is fine. Everyone needs a lift from time to time. But it only lasts so long. Some high achievers even say that it’s for amateurs.

Discipline is the key. Develop a habit of working on your goals daily. I again agree: easier said than done. Don’t forget why you’re here for.

Remote work

Remote work is a blessing in disguise. As well as this unfortunate situation, we found ourselves in this year.

You get to stay home.

Remember how you wished you could work from home?

Well, now, you do.

I get it; for some of you, it’s truly awful (both WFH parents with kids, I feel for you, hang in there 💪).

However, for everybody else, it is up to you in the end if you end up working towards your goals, or playing video games.

Remote work is not easy, and it’s not for everyone. I’m pulling a shameless plug here in saying that this post will help you if you want to ‘make it’.

What’s up with all the book references!?

I think that reading books is a great time investment. If you don’t have the time, I challenge you to find fault with the the math behind reading 30 books per year
.

Conclusion

I hope this helps, but remember: nothing beats one’s own hard-earned experience. Therefore, give these tips a go, see what works for you and adapt them to your style.

I wish you good luck in achieving them!

TL;DR

In this short post I’ll tell you:

• how we implemented our fourth book club idea in our engineering team
• what book we read
• how we liked it,
• and share a few key takeaways

You can read all about our other book clubs here:

• 1st – The Phoenix Project (has way more info on how we’re doing it)
• 2nd – It doesn’t have to be crazy at work
• 3rd – Pragmatic Programmer

⚠️ If you’re thinking that there’s no time to read the books, check this post on the math behind reading 30 books per year. If you think that this book club thing is cool, and you’d want to be a part of the group that’s ‘allowed’ to read ‘on the job’, shoot me an email 👍

THE BOOK

This time we read the Stealing Fire: How Silicon Valley, the Navy SEALs, and Maverick Scientists Are Revolutionizing the Way We Live and Work.

Here are the Amazon and Goodreads ratings:

DATA POINTS

• avg(time to read) = 10 hours
• avg(liked the book) = 6.1 / 10
• avg(liked the book club) = 8.7 / 10

In general, we didn’t quite like the book, and there was even a vote to stop and switch to another one. In the end, we persevered and thus such a high score for the book club itself.

KEY TAKEAWAYS

• We find the book interesting, but also really scary as it left us wondering what the 1% of 1% are doing to achieve the flow state
• A good part of what we’re habitually doing online is more to forget ourselves for a moment than inform ourselves for the long haul
• Time (and how to make the most of it) appears to be about five times more important to us than making love or money
• These days, we’re drowning in information, but starving for motivation.
• When a Harvard Medical School study confronted patients with lifestyle-related diseases that would kill them if they didn’t alter their behavior (type 2 diabetes, smoking, atherosclerosis, etc.), 87 percent couldn’t avoid this sentence. Turns out, we’d rather die than change.
• Eric Schmidt became Google’s CEO because he attended Burning Man
• We process more information when unconscious
• Surfing can get you in the flow state
• This book is like a commercial for drugs
• Eight weeks of meditation training measurably sharpened focus and cognition
• If coffee isn’t considered cheating, what makes smart drugs any different?
• Animals seek out drugs
• Slack prevents us from reaching (and staying in) the flow state
• It costs $25,000 to turn an average Joe into a combat-ready U.S. Marine.
• In 2014, EDM represented almost half of all concert sales, attracting a quarter of a million concertgoers at a time and drawing the attention of Wall Street investors and major private equity firms.
• Eight weeks of meditation training measurably sharpened focus and cognition
• Absolutely terrified knowing the final outcome of the Pied Piper story
• Stimulating the front part of the lobe causes visions of God

TL;DR

How about instead of just adding more new books to our read pile (and even more to the never-ending to-read pile), we revisit our list of the books that we’ve read and in 2020 we not just re-read them, but study them?

!TL;DR

Quotes are great

“The greatest satisfaction comes from mastering something that is truly difficult.”
~ Abraham Maslow

A positive fact

All of us are readers in this group, and we had to go through a lot of content to find the one that’s valuable. We can think of that as a process of getting the signal from the noise.

A sad fact

Even though we read a lot of books (and we may be looking into techniques to increase that number), we are not oblivious to the fact that there are just too many books and not enough time. Moreover so, we realize that after a certain amount of books that we’ve read in a certain category, the new ones are just not yielding the same ROI (I being the ever so slightly limited time). Most of them feel like they’re rehashing the ideas and are just geared toward the ‘current’ generation.

A little bit of math

Consider for a moment that we read 60 books per year (A lot, right? Well, here’s the math behind reading 30 in a year). What if, in 2020, instead of just adding new books to the read pile, we set a goal only to read 30 (half of that, so adjust your math accordingly, please). But with a twist.

The twist and the ?

What if we revisit all the books that we’ve read in our career so far and commit to not only re-reading them in 2020, but actually studying them? So that we won’t just know ‘oh, yeah, I read that somewhere in the XYZ book,’ but instead we’ll have the actual book in RAM if you will (with UPS, of course). Sure, I’d reserve a slot for 10 new ones just in case 🙂

For added points, please proceed here

I’d love to hear what you think about the idea presented above 🙏. And also, I’d like to learn what were the signal vs. noise books in your career so far? To not make this into some long list, let’s cap it at five books.

So how about you, mister?

OK, OK, thought I’d get away with it 😎, here’s my entry:

• Leadership and self-deception
• Time management made simple
• How to win friends and influence people
• Think and grow rich
• Little prince

Conclusion

One thing is definite: our time. Let’s use it as effectively as possible by reading the books that bring the biggest bang for the buck.

Here are my notes from the practical book Scrum: The Art of Doing Twice the Work in Half the Time.

Several of us were reading it as a part of a ‘smaller book club’ and we all echoed the same feeling about the book: we love it and will not only look to apply it in the work environment but also at home in our personal lives.

Ingredients for scrum

• Product Owner
  • What and Why needs to be done
  • Knows the market, the customer and has a vision
• Team (3-9 people)
  • Decide on the Who and How
• Scrum Master
  • Coaches the Scrum framework and removes waste
• Create and prioritize the Backlog
  • Constantly evolving
• Refine and estimate the Backlog
  • Planning Poker with Fibonacci sequence
• Sprint planning
  • Team, Scrum Master, and the Product Owner
  • Always of fixed length (from 1 to 4 weeks in general)
  • Velocity
    • Sum of points done in one Sprint
  • Sprint goal
    • Everyone has to agree on one sprint goal in the Sprint
• Scrum board
  • Has lanes ToDo, Doing, Done (we use Clubhouse)
• Burndown chart
  • Chart showing a number of points done per day
• Daily Stand-up or Daily Scrum
  • 15 min max meeting where you answer three questions:
    • What did you do yesterday to help the team finish the Sprint?
    • What will you do today to help the team finish the Sprint?
    • Is there any obstacle blocking you or the team from achieving the Sprint goal?
• Sprint review or Sprint demo
  • Show what was done in a Sprint
    • Show what’s totally finished by the DoD (Definition of Done)
• Sprint retrospective
  • What went right?
  • What could have gone better?
  • What is the improvement in the process that we as a team can implement right away (in the next Sprint)?
  • The process should be blameless – we’re looking at the process, not people!

Takeaways per chapter

• CH #1 – The way the world works is broken
  • Planning is useful. Blindly following plans is stupid.
    • It’s just too tempting to draw up endless charts. All the work needed to be done on the massive project laid out for everyone to see – but when detailed plans meet reality, they fall apart. Build into your working method the assumption of change, discovery, and new ideas.
  • Inspect and adapt
    • Every little while, stop doing what you’re doing, review what you’ve done, and see if it’s still what you should be doing and if you can do it better.
  • Change or die
    • Clinging to the old way of doing things, of command and control and rigid predictability, will only bring failure. In the meantime, the competition that is willing to change will leave you in the dust.
  • Fail fast so you can fix early
    • Corporate culture often puts more weight on forms, procedures, and meetings than on visible value creation that can be inspected at short intervals by users. Work that does not produce real value is madness. Working product in short cycles allows early user feedback and you can immediately eliminate what is obviously wasteful effort.
• CH #2 – the origins of Scrum
  • Hesitation is death
    • Observe, Orient, Decide, Act. Know where you are, assess your options, make a decision, and act!
  • Look outward for answers
    • Complex adaptive systems follow a few simple rules, which they learn from their environment.
  • Great teams are
    • They are cross-functional, autonomous, and empowered with a transcendent purpose.
  • Don’t guess. Plan, Do, Check, Act.
    • Plan what you’re going to do. Do it. Check whether it did what you wanted. Act on that and change how you’re doing things. Repeat in regular cycles, and, by doing so, achieve continuous improvement.
  • Shu Ha Ri
    • First, learn the rules and the forms, and once you’ve mastered them, making innovations. Finally, in a heightened state of mastery, discard the forms and just be – with all the learning internalized and decisions made almost unconsciously.
• CH #3 – Teams
  • Pull the right lever
    • Change team performance. That has much more impact – by several orders of magnitude – than individual performance.
  • Transcendence
    • Great teams have a purpose that is greater than the individual; e.g. burying General MacArthur, winning the NBA championship.
  • Autonomy
    • Give teams the freedom to make decisions on how to take action – to be respected as masters of their craft. The ability to improvise will make all the difference, whether the unit is reporting on a revolution in the Middle East or making the sale.
  • Cross-functional
    • The team must have every skill needed to complete a project, whether the mission is to deliver Salesforce.com software or capture terrorists in Iraq.
  • Small Wins
    • Small teams get work done faster than big teams. The rule of thumb is 7 members ± 2. Err on the small side.
  • Blame is stupid
    • Don’t look for bad people; look for bad systems – one that incentivizes bad behavior and rewards poor performance.
• CH #4 – Time
  • Time is finite. Treat it that way.
    • Break down your work into what can be accomplished in a regular, set, short period – optimally 1 to 4 weeks. And if you’ve caught the Scrum fever, call at the Sprint.
  • Demo or die
    • At the end of each sprint, have something that it’s done – something that can be used (to fly, drive, whatever)
  • Throw away your business cards
    • Titles are specialized status markers. Be known for what you do, not how you’re referred to.
  • Everyone knows everything
    • Communication saturation accelerates work.
  • One meeting a day
    • When it comes to team check-ins, once a day is enough. Get together for 15 minutes at the daily standup, see what can be done to increase speed, and do it.
• CH #5 – Waste is a crime
  • Multitasking makes you stupid
    • Doing more than one thing at a time makes you slower and worse at both tasks. Don’t do it. If you think this doesn’t apply to you, you’re wrong – it does.
  • Half-done is not done
    • A half-built car simply ties up resources that could be used to create value or save money. Anything that’s “in process” costs money and energy without delivering anything.
  • Do it right the first time
    • When you make a mistake, fix it right away. Stop everything else and address it. Fixing it later can take you more than 20 times longer than if you fix it now.
  • Working too hard only makes more work
    • Working long hours doesn’t get more done; it gets less done. Working too much results in fatigue, which leads to errors, which leads to having to fix the thing you just finished. Rather than work late or on weekends, work weekdays only at a sustainable pace. And take a vacation.
  • Don’t be unreasonable
    • Goals that are challenging our motivators; goals that are impossible are just depressing.
  • No heroics
    • If you need a hero to get things done, you have a problem. Heroic effort should be viewed as a failure of planning.
  • Enough with the stupid policies
    • Any policy that seems ridiculous likely is. Stupid forms, stupid meetings, stupid approvals, stupid standards are just that – stupid. If your office seems like a Dilbert cartoon, fix it.
  • No assholes
    • Don’t be one, and don’t allow the behavior. Anyone who causes emotional chaos, inspires fear or dread, or demeans or diminishes people needs to be stopped cold.
  • Strive for flow
    • Choose the smoothest, most trouble-free way to get things done. Scrum is about enabling the most flow possible.
• CH #6 – Plan reality, not fantasy
  • The map is not the terrain
    • Don’t fall in love with your plan. It’s almost certainly wrong.
  • Only plan what you need to do
    • Don’t try to project everything else years in advance. Just plan enough to keep your teams busy.
  • What kind of dog is it?
    • Don’t estimate in absolute terms like hours – it’s been proven that humans are terrible at that. Size things relatively, by what breed of dog the problem is, or T-shirt size, or, more commonly, the Fibonacci sequence.
  • Ask the Oracle
    • Use a blank technique, like the Delphi method, to avoid anchoring biases such as the halo effect or bandwagon effect or just plain stupid groupthink.
  • Planing poker
    • Use planning poker to quickly estimate the work that needs to be done.
  • Work is a story
    • Think first about who will be getting value from something, then about what it is, and then why do you need it. Humans think in narratives, so give them one. As an X, I want Y, so that Z.
  • Know your velocity
    • Every team should know exactly how much work they can get done in each Sprint. And they should know how much they can improve that velocity by working smarter and removing barriers that are slowing them down.
  • Velocity x Time = Delivery
    • Once you know how fast you’re going, you’ll know how soon you’ll get there.
  • Set audacious goals
    • With Scrum it is not that hard to double production or cut on delivery time in half. If you do it the right way, your revenue and stock price should double as well.
• CH #7 – Happiness
  • It’s the journey, not the destination
    • True happiness is found in the process, not the result. often we only reward the results, but what we are really want to reward his people striving towards greatness.
  • Happy is the new black
    • It helps you make smarter decisions. Plus, when you’re happy, you’re more creative, less likely to leave your job, and more likely to accomplish far more than you’ve ever anticipated.
  • Quantify happiness
    • It’s not enough to just feel good; you need to measure that feeling and compare it to actual performance. Other metrics look backward. Happiness is the future-looking metric.
  • Get better every day – and measure it
    • At the end of each Sprint, the team should pick one small improvement, or kaizen, that will make them happier. And that should become the most important thing they’ll accomplish in the next Sprint.
  • Secrecy is poison
    • Nothing should be secret. Everyone should know everything, and that includes salaries and financials. Obfuscation only serves people who serve themselves.
  • Make work visible
    • Have a board that shows all the work that needs to be done, what is being worked on, and what is actually done. Everyone should see it, and everyone should update it every day.
  • Happiness is autonomy, mastery, and purpose
    • Everyone wants to control their own destiny, and get better at what they do, and serve a purpose greater than themselves.
  • Pop the happy bubble
    • Don’t get so happy that you start believing your own bullshit. Make sure happiness is measured against performance and if there is a disconnect, be prepared to act. Complacency is the enemy of success.
• CH #8 – Priorities
  • Make a list. Check it twice.
    • Create a list of everything that could possibly be done on the project. Then prioritize it. Put the items with the highest value and lowest risk at the top of the backlog, then the next, and then the next.
  • The Product owner
    • She translates vision into Backlog. She needs to understand the business case, the market, and the customer.
    • Has knowledge of the domain and the power to make final decisions. Is available to answer questions and is accountable for delivering value.
  • A leader isn’t a boss
    • A product owner sets out what needs to be done and why. How the team accomplishes it and who accomplishes it is up to the team.
  • Observe, Orient, Decide, Act (OODA)
    • See the whole strategic picture, but act tactically and quickly
  • Fear, uncertainty, and doubt
    • It’s better to give than to receive. Get inside your competitors OODA loop and wrap them up in their own confusion.
  • Get your money for nothing and your change for free
    • Create new things as long as those new things deliver value all stop be willing to swap them out for things that require equal effort. What in the beginning you thought you needed is never what is actually needed.
• CH #9 – Change the world
  • Scrum accelerates all human endeavors
    • The type of project or problem doesn’t matter – Scrum can be used in any endeavor to improve performance and results
  • Scrum for schools
    • In the Netherlands, a growing number of teachers are using Scrum to teach high school. They see an almost immediate improvement in test scores of more than 10%. And they’re engaging all sorts a few students, from vocational to gifted.
  • Scrum for poverty
    • In Uganda, the Grameen Foundation is using Scrum to deliver agricultural and market data to poor rural farmers. The result: double the yield and double the revenue for some of the poorest people on the planet.
  • Rip up your business cards
    • Get rid of old titles, all managers, all structures. Give people the freedom to do what they think best and the responsibility to be accountable for it. You’ll be surprised at the results.

TL;DR

In this short post I’ll tell you:

• how we implemented our third book club idea in our engineering team
• what book we read
• how we liked it,
• and share a few quotes that we liked

You can read all about our other book clubs here:

• 1st – The Phoenix Project (has way more info on how we’re doing it)
• 2nd – It doesn’t have to be crazy at work

⚠️ If you’re thinking that there’s no time to read the books, check this post on the math behind reading 30 books per year.  If you think book club thing is cool, and you’d want to be a part of the group that’s ‘allowed’ to read ‘on the job’, shoot me an email ?

THE BOOK

• This time we read the Pragmatic Programmer

DATA POINTS

• avg(time to read) = 6 hours
• avg(liked the book) = 6.9 / 10
• avg(liked the book club) = 8.8 / 10

KEY TAKEAWAYS

• Quality is a team issue – the team as a whole should not tolerate broken windows

• Treat the documentation the same way you treat your code

• Prototypes are disposable and shouldn’t go into production

• Crashing early makes life a lot easier when debugging code

• Decoupling is good, but as a group, we don’t subscribe to the idea that your software needs to be so flexible that swapping out databases would just be as easy as changing a line of code

• Shell is way more powerful than GUI

• Don’t be a slave to old code, always be ready to refactor

• Don’t refactor and change functionality at the same time

• Take the time to spell out connectionPool instead of cp

• Treat code as gardening

• “Why” is more important than the “what” – don’t blindly duplicate existing workflow when translating into code from manual processes

• Try not to be a slave to the methodology

• Overengineering is as bad as under-engineering

• Premature optimization is bad

• Making a project glossary to save time later on looking for acronym translations is a good idea

• The code should have comments, but too many comments can be just as bad as too few

• Attaching codenames to new projects/features is cool

• Tailoring your message to the audience is an important skill to have

• Don’t tell your boss that it’s done until it’s tested

• Finding bugs early in the process saves money in the long run

• Learn a new language every year, and read a tech book every month and read non-tech books as well

• The word deadline comes from a line in prisons which if crossed by prisoners they’d get shot

• The book is mostly a refresher of techniques/ideas that we already know – new book coming out for 20th anniversary

Here are my notes from a very practical book The Coaching Habit by Michael Bungay Stanier:

The book covers 7 questions:

• Kickstart: What’s on your mind
• AWE: And what else?
• Focus: What’s the real challenge here for you?
• Foundation: What do you want?
• Lazy: How can I help?
• Strategic: If you’re saying yes to this, what are you saying no to?

• Learning: What was most useful for you?

• The essence of coaching lies in helping others and unlocking their potential

• If you need to have a lead in phrase, consider using: ‘out of curiosity’
• Three vicious circles that plague our workplaces: overdependence, getting overwhelmed, and becoming disconnected.
• Ask people more questions and give less advice
• 45% of our waking behavior is habitual
• If you spend too much time imagining the outcome, you’re less motivated to actually do the work to get there.
• Think less about what your habits can do for you, and more about how this new habit will help the person or people you care about.
• Charles Duhigg says that there are just five types of triggers: location, time, and emotional state, other people, and immediately preceding action.
• I will ask just one question and then be quiet while I wait for the answer.
• Coaching for performance is about addressing and fixing a specific problem or challenge. Coaching for development is about turning the focus from the issue to the person dealing with the issue, the person who’s managing the fire.
• 3P’s: people, projects, patterns
• The brain accounts for only 2% of the body weight, but it uses about 20% of the energy
• The first answer someone gives you is rarely the only answer, and it’s rarely the best answer.
• The brain counts like this: one, two, three, four…lots.
• Stop offering up advice with a question mark attached. That doesn’t count as asking the question. If you’ve got an idea, wait. Ask, “And, what else?”, and you’ll often find that the person comes up with the very same idea that’s burning a hole in your brain.
• The simple act of adding ‘for you today’ to the end of as many questions as possible is an everyday technique for making conversations more development than performance oriented.
• Stick to the question starting with “What” and avoid questions starting with “Why”.
  • Why did you do that? => What were you hoping for here?
  • Why did you think this was a good idea? => What made you choose this course of action?
  • Why are you bothering with this => What’s important for you here?
• The single biggest problem with communication is the illusion that it has taken place. ~ G.B. Shaw
• 9 universal needs based on Marshall Rosenberg: affection, creation, recreation, freedom, identity, understanding, participation, protection, subsistence
• Five times a second, at an unconscious level, your brain is scanning the environment around you and asking itself: it’s safe here, or is it dangerous?
• After asking a question, just patiently wait for an answer.
• Based on Karpman, there are three archetypal roles: victim, persecutor, and rescuer
• While talking nod your head, make encouragement noises and maintain
• Being busy is no measure of success
• The essence of strategy is choosing what not to do. ~ Michael Porter
• Acknowledge the reply of a person by saying, “Yes, that’s good”, instead of just going into another question.
• People don’t really learn when you tell them something. They don’t even really learn when they do something. They start learning, start creating new neural pathways, only when they have a chance to recall and reflect on what just happened.
• This is why, in a nutshell, the advice is overrated. I can tell you something, and it’s got the limited chance of making its way into your brain’s hippocampus, the region that encodes memory. If I can ask you a question and you generate the answer yourself, the odds increase substantially.x
• What have you learned since we last met?
• So, what was most useful here for you? What did you find most valuable about this chat? What worked best here?
• Finish on a high note, and you make everything that went before it look better.
• “Before I jump into a longer reply, let me ask you: What’s the real challenge here for you?

TL;DR

You can read all about how we implemented our 1st book club idea in our engineering team, and in this post, I’m going to do the same but with a new book. In this short post I’ll tell you:

• how we implemented the second book club idea in our engineering team
• what book we read
• how we liked it,
• and share a few learnings, comments and (as I usually do in my book posts) quotes

What book did we read?

We read the book called It Doesn’t Have to Be Crazy at Work by Jason Fried and David Heinemeier Hansson.

It seems that the Goodreads and Amazon reviewers liked the book.

However, I’m not really sure why, because this is how much we liked (or better said didn’t) the book. So, 4.5/10 with a max rating of 6 says a lot.

How did we do it?

We read it in only three weeks which means it was a really easy read. This comes down to about 75 pages per week, which amounts to 15 pages per work day.

On average, it took us 2hr and 22 minutes to finish the book, or about 9 minutes per work day.

Here’s a short post on the math behind reading 30 books per year in case you’re interested.

What did we like?

Even though we didn’t like the book in general, it still had some parts that we liked:

• Office hours idea
• Stance towards interviews – and paying for spec work
• Company is not a family
• Salary negotiation is crap
• Calm goodbyes
• Fridays off during summer

What we didn’t like

A lot of the chapters were common sense, and we agreed with them (few mentioned above), but some of the things we just couldn’t agree with:

• No goal setting
• Not going out of your comfort zone – promoting mediocrity
• It seems like the whole book is an advertisement for them
• They support multiple versions
• This most probably won’t work for a bigger company

Some quotes

As usual in my book posts, here are some quotes that we liked:

• We don’t mind leaving some money on the table, and we don’t need to squeeze every drop out of the lemon. Those final drops usually taste sour, anyway.
• There is nothing so useless as doing efficiently that which should not be done at all.
• Your company is a product. If you want to make the product better, you have to keep tweaking, revising, and iterating.

• Comparison is the death of joy.

Conclusion

Even though we didn’t like the book in general, it definitely wasn’t a total waste of time. We already started with the next book (Pragmatic Programmer), and this time we hope the book to be better.

A question for those that already conducted book clubs in your engineering organizations – what books did you read?