Hosk’s recommended Dynamics 365 and other articles November 2018

Quotes

IT projects are not about delivering technology they are about enabling users #HoskCodeWisdom

The most important thing in communication is hearing what isn’t said. – Peter F. Drucker

Articles of the Month

awesome-1

Great Dynamics 365 articles this month

Programming/Scrum

Other/Business/Leadership/Management

The Hosk – currently reading

The Hosk – last 5 recommendations

Selected  HoskWisdom

  • IT projects are complex, difficult and all about people #HoskCodeWisdom
  • Released code hides problems, bugs magnify them #HoskCodeWisdom
  • The more problems you find in design , the less panicking you do in delivery #HoskCodeWisdom
  • Passion in developers is great but only when combined with competency #HoskCodeWisdom
  • Code is like a fart. You love your own and disgusted by other peoples #HoskCodeWisdom
  • An architects diagram without a developer, is just a dream #HoskCodeWisdom
  • Days writing code go slow, projects go fast #HoskCodeWisdom
  • A good plan implemented badly gets the same results as a bad plan implemented well #HoskWisdom
  • Time is limited but few people act that way
  • The shower is where ideas rain down upon you
  • If you can’t control it, don’t worry about it
  • The opportunity to over think things is only a decision away

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

Advertisements

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.

Interesting resources for Dynamics professionals from Ignite 2018

Learning never stops, never ends, never finishes

Ignite has a wealth of resources for Dynamics professional.  The problem is not having enough videos to watch, the problem is there is too many and finding the ones interesting to Dynamics professionals.

I have picked out some of the presentations that look interesting.  I haven’t watched them all but I have watched a bunch of them.

This has been really useful to see how the changes, new features and new services (PowerApps, Common data service, Logic Apps, Flows) fit into future projects.

Interesting resources for Dynamics professionals from Ignite 2018

Successful people are constantly learning

Change will make or break your project

“It is always easier to talk about change than to make it.” ~ Alvin Toffler

Change will make or break your project, changes can‘t be controlled your reaction can.  A fixed mindset breaks instead of bends when confronted with change.  Change is constant, some don’t adapt, others adapt enough to survive, a few use change to be successful.  The less rigid and more adaptable you are, the fewer times you get stuck.

Technology, resources, environment and tools change, it costs you time and effort to change but the cost of not changing will be higher.  What was successful in the past, might not be successful in the future.  By focusing on the past, you won’t be prepared for the future.  The past has gone and can‘t be changed but the future is yet to be defined, embrace change and improve your situation.

Code and change

The art of develop lies in the constant adjustments to change

Robust code is decoupled, ensuring it can adapt to the evolution of requirements and manage the effects of change.  Agile development leaves design decisions to as last as possible, giving more time to gather information and decide based on better understanding.

Requirements and solutions evolve, the more detail you uncover, the more feedback you receive the greater your awareness of the problem and the solution.   You can’t capture requirements up front and get a deep understanding without going through iterations of designs and problems.

Project change

A project won’t change but you can change yourself and the approach to be successful.  A project which does not adapt to the changes will fail.  We are servants of projects, they will tell you when it‘s not working.   Think about the pain points, how could this work differently.

Nothing is fixed, people, requirements, technology and politics change, be fluid, formless and adaptable.  Take a flexible approach, what was successful on previous projects might not be successful with these requirements, environments and people.  When you think requirements are certain, you risk creating brittle designs and brittle plans that will break when change happens.

It’s not if change happens but when and how you react.

Projects evolve, the design at the start is not the functionality in production.  This is because the requirements change with understanding and feedback.

Each projects rhythm is unique and the most efficient way of working different.  You have to adjust and keep improving, finding a smoother way to move functionality from requirements to production.

Conclusion

Don’t fight change and don’t wait for it to happen, embrace change and use it as an opportunity for improvement.  Change is not comfortable or easy and involves conflict but through this something better emerges.

Knowing change is coming won’t make it easier because you will need to move past the friction but it’s the only way to make progress

Hosk’s recommended Dynamics 365 and other articles October 2018

Quotes

Some solutions are so complex, only an architect could create them

There are two great days in a person’s life – the day we are born and the day we discover why. William Barclay

Articles of the Month

awesome-1

Great Dynamics 365 articles this month

Programming/Scrum

Other/Business/Leadership/Management

The Hosk – currently reading

The Hosk – last 5 recommendations

Selected  HoskWisdom

  • To a developer, every problem looks like it needs code to fix it
  • All future development roads lead through CDS, PowerApps and Flow. So start heading in that direction now
  • Architecture is where the fun is, Development is where the pain is felt
  • You have to battle with code more than once, to make it maintainable
  • You’re only as good as the code you create
  • Projects approach methodology like people approach religion, they don’t implement all of it and use the bits they like
  • Write great code if you can, refactor when possible but get the job done
  • Technology should not dictate solutions, it should enable solutions

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

Write your code, do your job, focus on the details, predict problems

You’re only as good as the code you create #HoskCodeWisdom

It’s easy to get distracted by the noise of work but it puts more pressure on yourself and your team.  If everyone focused on their role and responsibilities, doing their tasks to the best of their abilities we get more done and it will be to a higher quality.

People get distracted by

  • The internet
  • People
  • Are other people doing their job properly
  • Helping other people do their job
  • The quality of the whole code base
  • New tools, new features, new services, new everything
  • New JavaScript languages
  • Is the project going to fail
  • What is the customer doing?
  • What’s for lunch

There will be noise, distractions and under performing people but don’t add to those problems by letting them distract you.  When you become distracted, you are lowering the quality of your work by diverting time, effort and thought to something else or someone else.

Write your code

Do your job first, do it a high standard, work consistently, finish.  Focus on the details and uncover potential problems.  It’s in the details where the assumptions, logic error, design flaws you don’t see until you drill down into the task at hand.

If everyone did their job and stopped worrying or helping other people do their jobs,  process will work with greater efficiency.

Start by doing your job to the best of your abilities, write the best code you can,  so no one else has to worry.

People who make an impact at work are not just the leaders at the front but the people in the engine room, contributing code, delivering functionality in a dependable way, they are the people who reduce the noise and get it done.

What is development?

Writing good code requires solid fundamentals, working hard and focusing on the task.If each developer does this then the project progresses well and confidence builds within the team and with the customer.

Coding isn’t about flashes of brilliance, innovative designs, hero’s saving the day, it’s about team work, graft and grit.  Turning up every day and working towards the goal, one line at a time.  Wearing problems and requirements down with persistence.

Development is everyone doing the basics and pulling in the same the direction, people who get distracted and head off in another directions, pulls the project in the wrong way and slows everyone down.Get your work done and don’t add to the distractions

Related articles

 

Dynamics 365 FastTrack Architect Bootcamp training in Frankfurt

The more you learn, the further you go #HoskWisdom

One of the great things for working for Capgemini is they want individuals to grow and improve.  This means I get to go to training and events.  Early this year I went to Extreme 2018 in Dubrovnik

This week I am on the Dynamics 365 FastTrack Architect Bootcamp.  The course is run by some of the Fast Track engineers who work on Microsoft biggest projects as part of the FastTrack scheme.

Phil Hand will be presenting and I read a white paper from him which helped me create this blog post on solutions

CRM 2016 – What’s the best way to organise solutions in Microsoft Dynamics CRM  

FastTrack bootcamp is also available for Operations

What is FastTrack?

FastTrack is offered to larger customer (250 seats plus) and the FastTrack team get involved to guide the customer and partner to make sure the project is successful.

This page is offers a good overview of FastTrack and what it’s all about

FastTrack for Dynamics 365 is our customer success service designed to help you move to Dynamics 365 smoothly and confidently, so you can realize business value faster. When you participate in the FastTrack program, you will receive guidance on best practices and how to plan for successful rollouts. You will also learn ways to enable new users and expand capabilities – all at your own pace. Additionally, you will have access to Microsoft engineering resources committed to make your experience with Dynamics 365 a success.

The FastTrack offers skype sessions, workshops and regular touch-points to make sure the customer is on track.

If you are eligible for the FastTrack program then Microsoft will be involved in your project and help ensure the successful implementation of Dynamics 365 by using their FastTrack process and experience implementing Microsoft Dynamics 365.

Microsoft’s FastTrack team isn’t one or two people but many different experts.

Whats covered

It’s a 4 day intensive course, which covers most aspects of a Dynamics project

You can see the course agenda here

The highlights are

  • Dynamics 365 Online Architecture
  • ALM and Solution Release Management
  • Integration Architecture / Patterns
  • Data Migration Approaches / Patterns
  • Dynamics 365 Reporting Strategy / Architecture Patterns
  • Field Service Architecture / Best Practices
  • Project Service Architecture / Best Practices
  • Security and Data Modeling
  • Performance Optimization Best Practices
  • Unified Service Desk Architecture
  • Portal Architecture / Best Practices
  •  Microsoft Business Flow/Power App
  • Dynamics 365 Testing

Pictures of my adventure

Here are some pictures of my adventure in Frankfurt. I wondered around a lovely day in Frankfurt by myself and had some frites

Hosk art selfie

Art Museum

 The bridge 

Nice River

Statue

Massive Euro?

The Flight

Frankfurt river