Overview
We will be sharing our expertise and knowledge through our articles. There are many tutorials on the market which show how in one context. There are very few which follow our teaching formula.
Our secrets for teaching are:
●Start where the person is at with his/her own understanding and abilities
●Then incrementally move that person forward.
●Deeply teach the how and why
●Break it down and prove it.
Facts:
Let’s embrace these facts and propagate them in all that we do:
●Software is a thinking profession
●Innovation is driven from deep technical proficiency
●Proficiency is built off of a deep understanding and relationship with the technology and code
●There are many ways to solve a problem
●What matters is clean, quality code
●There is no such thing as “best” practice.
●Change is a fact.
Guidelines
The Do’s
Each article that we produce should:
●Educate
●Show. Don’t tell
●Deeply teach the why
●Invite the reader to think for him/herself
●Show different adaptations (when possible)
Educate
We are educators. It is centric to our mission and what makes us unique in the market. We must ensure we are teaching in every article by our formula.
Show. Don’t tell.
People embrace a concept when they identify with it. They need evidence and prove. They need to see examples that they can understand.
When we write coding articles, we need to put that code into action and show they the crux of what we discussing in the article.
Deeply teach the why
Technical proficiency and deep understanding comes when you fully comprehend and embrace “the why” of the concept. When you “get it”, then you are able to adapt it to different situations and needs. Otherwise, you remain in that follower mode of because WPDC or whomever says so. Deeply knowing the why drives innovation and excellence.
The why separates us from everything else on the market. It’s one of the secret ingredients in our formula.
Invite thinking
Use the word “think” frequently. It is an active verb which is very powerful.
Software is a thinking profession. Period. Discussion, questioning, and debate are good things as then people are thinking for themselves in their journey to deeply understand. Invite the reader to think for him/herself.
Show different adaptations
The fact is: there is more than one way to solve a problem. In software, there many different ways to code. Showing the code in a different way or pattern, helps the person to visualize different implementations. It helps him/her to grow and think.
Different adaptations can be different design patterns to solve the exact same problem. For example, accessible font icons could be done with span or SVG along as they accompany the the proper aria. Another example is showing code in OOP and procedural. One more is using _s vs. Genesis vs. some other theming front-end framework.
The Don’ts
As a company, we need to refrain from using or driving the concepts of:
●Best practices
●One paradigm or practice is best
Don’t: Best Practices
There is no such thing as best practices.
It is a moving target and subjective to the opinions of a select group and trends of a period of time.
When you read “best practice,” it is interpreted as “this is the only way to code this the right way.” That’s just plain wrong. It’s not true. There are many different ways to solve the same problem. There are many design paradigms, standards, and patterns.
There are bad practices. Definitely. There are so-so practices. There are a collection of better practices. There is no definitive “best” practice.
Let’s not use “best” practices or embrace this concept. We can talk about what some group names as “best practice” and then discuss it; however, we should not say one practice is the definitive best out of all the others.
Don’t: One is best
Let’s never say one design paradigm or pattern is the definitive best. The fact is you can write quality, clean code in OOP, functional, and procedural. You can use prefixing or namespacing. You can use grunt or gulp.
This “don’t” ties in with best practices. As engineers, it’s so easy to get wrapped up into our own mindset and practices to exclude other methodologies. It’s easy to become code snubs and declare OOP is the only and best way to code or this framework is the only one to use.
I’ve seen this narrow focus in all disciplines of engineering. It’s not just a software specific problem.