Why avoiding being wrong is slowing your progress

You got to go down a lot of wrong roads to find the right one. Bob Parsons

Is your goal being right or getting to the right solution?  People go to lengths to avoid being wrong but tomorrow will it matter whose was right or who came up with the idea?

Being wrong is the path to success with a detour.  We seek out when we are wrong, understand why and move on.  Our ego demands we right, our feelings hate being wrong but the quickest way to improve is by failing and feedback from others.

Admitting you are wrong is short-term pain for long-term gain.

When you can handle being wrong, you end up being right.  An interesting TED talk being wrong by Kathryn Schulz
https://www.ted.com/talks/kathryn_schulz_on_being_wrong?

People spend time to avoid being wrong but it’s quicker to try, be wrong and move on. The time wasted on avoiding being wrong could be used on working on trying new ideas.

Being wrong is painful, you feel stupid, frustrated but this is your reaction to the event, when you reflect later its positive, you learned a lesson and corrected your path.

It’s difficult to admit being wrong because it‘s initially painful to admit being wrong publicly.  The goal is to do it right, how you get there isn‘t important tomorrow, so try to keep your perspective long-term.  You learn by doing and often learn more by doing it wrong because you stop to understand your mistake so you can avoid it in the future.

We  learn less from success because we don’t reflect on what we did right and assume we will do it again

Is it important to be wise? do you want to be right or do you want the right answer?  If being right means you personally are wrong, would you take it?

Code reviews

Code reviews are great for learning, an experienced developer checks your code, highlights bad code and suggest improvements.  Despite the benefits it feels like the reviewer is critising your code but attacking you as person.  This is an emotional reaction to being wrong and being critised, we have to overcome this with logic and understand this feedback is a great way to improve quickly.  It leads to a higher quality code base and developers write better code, helping individual’s long-term prospects.  It’s beneficial but not easy but it gets easier with practice.

Reactions are emotional, they happen quickly and bypass thinking, the reaction is to defend your code.  You respond by attacking, they defend and then they react and attack.  The topic of the discussion is lost in the emotional responses, defending and attacking the ego.  Time  on your ego and being right, short-term gains drive this behaviour.

The long-term logical view is to focus on learning, getting feedback and getting to the right solution.   Winning arguments come at the cost of learning , you learn when listening.  Winning an argument means you end the discussion with the same view as you entered, talked more than you listened and learnt nothing.  There is no winning when arguing.

Your goal as a software engineer is continuous improvement, being wrong, making mistakes and honest feedback are good teachers.  We learn more from being wrong because we stop to analyse, when we are right we assume we have done it right once and we will do it right again.

knowledge is powerful

Long lasting change comes from knowledge and the ability to use that knowledge effectively and to write better solutions. Static Code analyzers help highlight code which breaks best practice.  This is frustrating initially when lots of your code triggers error but learning the logic behind the rules helps grow your knowledge.

When you copy and paste code you bypass the learning and don‘t acquire knowledge.  Its like getting the answers to a test, you pass that test but you don‘t have the knowledge to pass other tests on the same subject.

Understanding allows you to alter solutions and adapt your knowledge to solve to different problems.  If you have copied the answer from the internet this brittle solution will break as soon as problem changes.  You can’t adapt solutions which you don’t understand.

Conclusion

Embrace being wrong, it’s a step on the path to understanding and developing a deeper knowledge of your area of expertise.  Our fear of being wrong is exaggerated, people respect someone for admitting and fixing their mistakes.

Mistakes occur when pushing yourself and doing things you don‘t have experience in.  Getting out of your comfort zone, working through mistakes is how to improve at a fast rate.  Playing safe and avoiding errors results in not learning and highlights you are playing too safe.

The focus should not be on being right but creating the right solution.  If you can avoid fearing being wrong, you will try harder things and push yourself to do more.  Admitting mistakes and avoid wasting time arguing or avoiding being wrong allows you to do more.

Building your tolerance for mistakes is the path for faster growth and improvement.

Advertisements

Hosk’s recommended Dynamics 365 and other articles September 2018

Quotes

The pain of legacy code never goes away

Writing code is a long lesson in humility #HoskCodeWisdom

 

Power is like being a lady… if you have to tell people you are, you aren’t.” – Margaret Thatcher

Articles of the Month

awesome-1

Great Dynamics 365 articles this month

Programming/Scrum

Other/Business/Leadership/Management

The Hosk – currently reading

The Hosk – has read and recommends

Selected  HoskWisdom from September

  • No Developer likes to be told they have ugly code
  • Meaning can come from great suffering, just ask anyone who has worked on an IT project
  • You can’t refactor code until you understand what it does
  • To many people try to do Agile when they should focus on being Agile #HoskCodeWisdom
  • The complexity of code is proportionate to the stress of supporting it #hoskcodewisdom
  • There is a game Microsoft likes to play with developers, They call it Master and Servant. It’s a lot like life and that’s what’s appealing

Last months Monthly articles

Last months recommended monthly articles

Hosk’s CRM Developer Articles

A collection of my favorite CRM Developer articles I have written

Why apprentices work well with Dynamics development

Youth is the gift of nature, but age is a work of art. Stanislaw Jerzy Lec

It’s not the quality of the plan but the quality of the people that is vital to success #HoskWisdom

Capgemini has a degree apprentice scheme which offers an alternative to going to university, it allows you to study for a degree funded by Capgemini, whilst working full time.

In 2018 Capgemini are hoping to add 90 apprentices.   Watching apprentices grow and improve is like a home-grown player making the football team, it feels more rewarding.

The Capgemini Dynamics team added at least two apprentices each year for the last 2 years and it’s worked well.

The cost of degree?

The cost of degrees in the UK is huge, students pay back via a percentage of their wages for 20 years after graduation (the degree gets them a better paying job and worth the investment)

With degree’s costing so much money, I’m surprised alternatives or getting a degree at university is still the popular choice.

Alternatives such as

  • Making degrees into 2 years (do you need 3 months off for summer?)
  • Night school
  • smaller focused courses relevant to software engineering/programming or other specialisations

The cost of a degree is £9000 per year (tuition fees, excluding living costs) lasting 3 years, people should question

  1. Is a degree worth the money?
  2. is a degree worth the time?
  3. What are the alternatives?

The Capgemini Dynamics team experience

we had at least 2 apprentices each year for the past 2 years and it worked well.  The apprentices are put onto projects and work as Dynamics developers.

Recent articles on apprentices on the Capgemini Dynamics team blog

Apprentices often learn faster than experienced developers who have learnt bad habits.  The Capgemini Dynamics team bring the best practices of software engineering to Dynamics development

  • Plugin framework
  • Unit testing
  • code using business logic and repository pattern
  • DevOps (CI, CD)
  • GIT not TFS (pull requests differ from check ins :-))

The apprentices pick up the development process often quicker than experienced developers because they haven’t got use to writing code without designing their code or writing unit tests.

Some CRM developers don’t see the value of unit tests but if you are working on a large projects and don’t write unit tests the quality of your code base will deteriate.  The effects of reduce quality code is harder to read, maintain, test and extend your code; The project will slow down and make any changes costly in terms of time and money.

Articles on why you should unit test

Articles on designing code and technical debt

My experiences

The apprentices are are expected to

  • Contribute ideas
  • One Microsoft Dynamics Certification each year
  • Share information with the team (presentations, blog posts)

These help the software engineers learn about Dynamics 365, integrate and get engaged with the team.  Studying for Dynamics certification allows apprentices to learn Microsoft Dynamics 365 quickly and learning good software engineering principles takes longer.  Using frameworks and code reviews you can make sure junior developers creating code the right way.

Junior developers work best on a project with experienced developers who help them with the intricacies of Microsoft Dynamics development (which has it’s idiosyncratic ways of doing things).

Summary

Its a great way to get a degree and Dynamics project experience without the debt (it does take longer to get your degree)

You need to be hard working and dedicated to take this route but the benefit is you get your degree paid and project experience.  The downside is it takes longer to finish the degree and you need to study and work.

It’s amazing to think of the practical experience the apprentices get working on projects, learning from software engineers whilst people studying at university only have theoretical knowledge.

I look forward to the Capgemini Dynamics team getting more apprentices each year.  You can find out more here if you want to learn more about it.

The Hosk is writing again

Never be afraid to throw away all your ideas and start again with a blank page #HoskWisdom
Either write something worth reading or do something worth writing. Benjamin Franklin

Tasked with creating the social media strategy for the Capgemini Dynamics team, it has got me back into the habit of writing.  I have created a Capgemini Dynamics publication (https://medium.com/capgemini-dynamics-365-team) on Medium and share the good practices and great work the team are doing.  It will include other team members contributing posts as well my writing

This  prompted me to write on my blog – Why developers should read books, I enjoy thinking and writing (publishing your best thoughts).  Writing is a tool for teaching yourself and extracting knowledge from experience through reflection.

Busy busy busy

Why wait for tomorrow, when you can start today #HoskWisdom

I have been busy with project work, thinking and reading that I neglected to write, I got out of the habit.  Everyone is busy making excuses, to explain why they aren’t doing what they really want to be doing, you have to admit it and change.

It doesn’t feel I stopped writing blogs because there are tons of notepads and Evernote pages full of half-written blog posts.  Writing clarifies thought and helps you understand your approach to problems.

Writing

I enjoy the writing process because thinking about a subjects helps you understand.  Many thoughts don’t make the finished post because one thought leads to another.  The quality of thought and understanding grows with each thought.  At the end you step back and view all your ideas and take the best bits and organise them into an interesting structure before sharing it with the world.

I’m going to extreme 365 in Dubrovnik because of my blog, another reason I’m thankful to my blog.

Older blog posts are thoughts, experiences, challenges and problems I experienced, there are over 1000 posts and I can’t remember most of them but I don’t need to because I can go back and read them.  I view the blog as a storing my thoughts and knowledge in the cloud with the benefit of being searchable by myself and others.

Be ready to read more Hosk writing this year

Dream big but start small #HoskWisdom

Hosk’s Top Dynamics 365 Articles of the week – 14th – August

Quotes

But man is not made for defeat. A man can be destroyed but not defeated. Ernest Hemingway

Articles of the week

awesome-1

Best of the rest

Programming/Scrum

Other

The Hosk – currently reading

Hosk’s CRM Developer Articles

A collection of my favorite CRM Developer articles I have written

CRM 2016 – Tips on passing the MB2-712 customization and config exam

All the CRM 2016 content to help you pass the exam

picture from here

The difficulties of scaled agile projects

There are many projects which are Agile in name but chaos in reality #HoskWisdom

The Agile framework is like a person with a hammer, all problems look like nails and all projects look like Agile projects #HoskWisdom

 

Agile/Scrum used on large/enterprise projects with multiple Scrum teams, scaled Agile increases the complexity of a project and if not managed, adding more people can slow projects because there is a cost to adding more people to a project and increasing complexity.

Many agile project require an increase in velocity to meet an earlier completion date, the common method is to add more people to the project.

These Brooks quotes, author of the Mythical man month are apt
Adding manpower to a late software project makes it later. Fred Brooks
The bearing of a child takes nine months, no matter how many women are assigned. Fred Brooks

Adding more resources (usually developers) to a project would seem sensible.  If one team have a velocity of 25 story points Sprint (Story points gets internally translated to days by 91 percent of the population #HoskWisdom).  So if there are 4 teams a velocity of 100 story points per sprint.

The reality is teams and individuals don’t start delivering 100 percent instantly because there are other factors to consider.

Increasing people on a project increases complexity of working, collaborating and communicating #HoskWisdom

These other factors have been explained by Brooks Law

Brooks Law

 Brooks points to the main factors that explain why it works this way:
  1. It takes some time for the people added to a project to become productive. Brooks calls this the “ramp up” time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.
  2. Communication overheads increase as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people.[3]Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.
  3. Limited divisibility of tasks. Adding more people to a highly divisible task such as reaping a field by hand decreases the overall task duration (up to the point where additional workers get in each other’s way). Some tasks are less divisible; Brooks points out that while it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”.
The problems associated with adding new teams is ramping up, individuals need to learn/understand
  • Business logic
  • Project processes
  • Best resources for situations
  • Project politics
  • Collaborate with others

A scrum team takes 2 sprints to get up to  speed, usually 50% efficiency for sprint 1 and 60/70% in Sprint 2.  When you add the added overhead of trying to collaborate with other teams this can slow new teams further and slow existing teams.  

Deadlines are the common cause of adding more people to a project which adds more pressure to the project and the newly arriving people.

A big overhead is integrating the work from multiple teams into one solution, even with continuous integration there will be problems when bringing solutions together

 

Sutherland one of the creators of Scrum mentions scaling in this article

InfoQ: Now that more and more larger organizations are using Scrum, the need for scaling increases. Can you give some suggestions how organizations can scale Scrum?

Sutherland: Scrum is designed to grow like a biological system. To create a baby, you need one good cell that replicates. If this cell is bad you have a lot of problems. So the challenge is to first get a single team successful to use as a model for other teams, then replicate it. As you grow, Scrum as large follows the same basic principles as Scrum in the small. If it doesn’t you have introduced waste into the system. You will build out organ systems, just as in the human body that have some specialization and need some training on how to handle cross team coordination, elevating impediments all the way to senior management, avoiding the introduction of unnecessary teams that can compromise performance, and scrumming the entire organization.

We have published several papers showing that a properly scaled Scrum can provide linear increases in global velocity, something never seen before in software development. However, you need to do Scrum really well to make this happen.

Hosk thoughts on scaling agile projects

The first rule of large agile projects is not to do large agile projects #HoskWisdom

Large Agile or Scrum projects are difficult but this doesn’t mean Agile/Scrum are not right for large projects because large projects are difficult and have similar problems no matter the framework or methodology used.

Agile projects have an extra dimension because quick decisions are needed from empowered product owners to give Scrum direction and feedback

Having multiple teams adds the need for more communication and collaboration and managing dependencies between teams.

There are lots of different scaled agile frameworks, many of them discussed in article below

Comparing scaling agile frameworks

Most of the frameworks try to solve problems with shared resources between teams and collaboration between teams (Scrum of Scrums meeting).

If you want existing teams working efficiently, you must remove project level impediments before adding new teams.  When a team works well then try adding one more team at a time.

There are other reasons for project troubles

Is Safe Evil

Conclusion

Big projects are difficult, hard and challenging and having people with experience of large projects helps.  There is pressure with big agile projects because sprinting and collaborating create conflicts and complexity.

Stick with the processes and aim to keep improving your processes and relationships.  Challenging projects are the most satisfying to deliver because you have to work hard and earn the achievement of a successfully delivered project.

A few last great quotes from Fred Brooks on why projects are delivered late
Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster. [page 14]

How does a project get to be a year behind schedule? One day at a time. Fred Brooks

picture from here

The Top 10 Hosk Dynamics CRM blog posts for 2016

Once you replace negative thoughts with positive ones, you’ll start having positive results. Willie Nelson

The company that needs Microsoft Dynamics CRM, and hasn’t bought it, is already paying for it #HoskWisdom

I have written Dynamics CRM blogs for 6 years and this year I got the most views in a year 673873,  beating last years numbers 661057.  Thanks to all the people who read my blog posts and support the Hosk Dynamics CRM blog post.

I have written blog posts so long the default category is CRM 2011!

A lot of people have told me this year how the Hosk Dynamics CRM blog post has helped them which is great.

Here is a list of the most viewed blog post in 2016 (I am always tempted to write CRM 2016, that will now stop with Dynamics 365).  The views don’t include articles viewed on other sites.

Home page / Archives 48326
CRM 2013 – Understanding Solutions and how they work 13408
Microsoft Dynamics CRM Developer Interview Questions 12904
CRM 2013 – Step by Step Update Plugin Tutorial using the CRM 2013 Development Toolkit 11382
What are the limitations of Microsoft Dynamics CRM Online and how do you work with them? 10162
CRM 2015/CRM2013 – JavaScipt to get the current users name 9753
CRM 2013 – Javascript to get id of current record 7370
CRM 2015 – how to find Statecode value 7141
MB2-703 – CRM 2013 Customization and Configuration Certification Information 7131
CRM Plugins – Stopping infinite loops and understanding PluginExecutionContext.Depth 7005
Where is the CRM Developer toolkit for CRM 2015? 7004

image from here