Blog


>Fall in love with some activity, and do it! Nobody ever figures out what life is all about, and it doesn't matter... Nearly everything is really interesting if you go into it deeply enough. Work as hard and as much as you want to on the things you like to do the best. <cite>Richard P. Feynman</cite>

Hi, my names **Kealan Parr**. I'm a **Senior Software Enginner** at Auden, with four years experience. 

A few years ago I was finishing my Biology degree and had to do some basic programming for my Biological data. I ended up more interested in the programming on my data I was doing than the biological data I was collecting.

I knew I had to side step into coding.

So I finished my Biology degree with a first class honours, and started working through [freeCodeCamp](https://www.freecodecamp.org/) certifications. You can view them [here](https://www.freecodecamp.org/certification/kealan-parr/javascript-algorithms-and-data-structures) and [here](https://www.freecodecamp.org/certification/kealan-parr/responsive-web-design)

Whilst I was at University, I also joined the [Royal Naval Reserves](https://www.royalnavy.mod.uk/our-organisation/bases-and-stations/training-establishments/university-royal-naval-units) and attained a foundation degree from the Chartered Management Institute in Business Administration and Management.

I then worked at bet365 on a placement for 2 years as a Junior Software Engineer, was kept on past my placement, promoted to Software Engineer and left after around 4 years there.

I also have a side business where I do paid technical writing you can learn more [here](https://kealanparr.com/writings.html)

The languages I know and love are: JavaScript/TypeScript, React, go, Node and Swift.

I have a collection of side projects I enjoy doing/did to learn something new:
- I transcribe images on Reddit weekly, for visually impaired people to ensure images are accessible.
- I have a profitable side-business where I do consultancy. Primarily, freelance writing and reviewing of technical documentation. 
- I created a repo called ["Every link I wish I had as a beginner"](https://github.com/kealanparr/Every-link-I-wish-I-had-as-a-beginner)- which details a host of useful links and resources to help less experienced developers. This has a CRON job to run a Node script monthly, to ensure none of the links undergo [link rot](https://en.wikipedia.org/wiki/Link_rot)
- I made a [basic JavaScript script](https://github.com/kealanparr/Chrome-dino-script.) to automate playing the [offline Chrome dino game](chrome://dino/) (that link only works in Chrome!)
- I have a [personal site](https://kealanparr.com/) I keep updated with what I'm upto
- When I was first learning Go and Docker, I made a [golang blog](https://github.com/kealanparr/go-blog) that connects to a containerised Database
- I was fascinated with Path finding algorithms, so I implemented [Djikstra and A*](https://github.com/kealanparr/pathFinder.js). I then made [Conways Game of Life](https://github.com/kealanparr/Conways.)
- [DeveloperForge](developer-forge.com) is updated by me, a Next.JS Static Site
- I made a [website](https://einsteins-riddle.com/) to solve [Einsteins Riddle ](https://www.freecodecamp.org/news/einsteins-riddle/)
- As part of an interview process, I made a [candidate-checker](https://mysterious-hollows-01965.herokuapp.com/) in go. Try typing "kealan parr" into the box! Or try "joe bloggs" as another example.

I love to keep upto date with the software field in general, and am a member of [ACM](https://www.acm.org/) and the [Unicode Consortium](https://unicode.org/consortium/consort.html)

I love to play Chess, and have played 4,500 games online (though I am still rubbish despite these games!)

*Thank you for reading!*

About Me


I love reading. In the past, I have set myself challenges to read a book a week for a year, across a mixture of technical and non-technical content.

I keep this list purely as a reminder of the (profesional development) books that I have read.

- CQRS, the Example by Mark Nijhof
- The Slight Edge by Jeff Olson
- Freakonomics by Stephen J. Dubner and Steven Levitt
- Think Like a Freak by Stephen J. Dubner and Steven Levitt
- Who Moved My Cheese? by Spencer Johnson
- Extreme Ownership: How U.S. Navy SEALs Lead and Win by Jocko Willink and Leif Babin
- So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love by Cal Newport
- Deep Work by Cal Newport
- How to Become a Straight-A Student by Cal Newport
- The Phoenix Project by Gene Kim, George Spafford, and Kevin Behr
- The Self‑Taught Programmer by Cory Althoff
- Practical DevOps by Joakim Verona
- Mastering TypeScript by Nathan Rozentals
- The Pragmatic Programmer by Andy Hunt and Dave Thomas
- The Standout Developer by Randall Kanna
- The Coding Career Handbook by Shawn 'swyx' Wang
- Code Reviews by Dr. Michaela Greiler

If there is a good book you think I should read, please contact me via this site and tell me, I would love to read it! :)

Books Read

If you want to chat regarding: something broken on the site, a missing software principle, a question you have for me or anything else - please reach me on the below contact button.

Contact


Engineers are constantly learning new things.

New software patterns, paradigms, ways of working, code structure, languages, libraries, frameworks *etc*

Good engineers I know are constantly trying to maximise their learning to make themselves even better at what they do.

I have had to do this too & continually read, write and develop to become a better coder.

So as I learn new things, I will endevaour to add the useful resources to the list.

This is just what helped me, if there are better resources, contact me via this site - and let me know!

- [How to learn Docker](/how-to-learn/docker/)
- [How to learn Go](/how-to-learn/go/)
- [How to learn Kubernetes](/how-to-learn/kubernetes/)
- [How to learn Math](/how-to-learn/math/)
- [How to learn Micro-frontends](/how-to-learn/micro-frontends/)
- [How to learn React](/how-to-learn/react/)
- [How to learn Webpack](/how-to-learn/webpack/)


How to Learn


Firstly watch [this](https://www.youtube.com/watch?v=iqqDU2crIEQ)

and then watch [this](https://www.youtube.com/watch?v=i7ABlHngi1Q)

Then, mess around in a Docker [playground](https://labs.play-with-docker.com/)

Disect a Docker file [here](https://gist.github.com/adamveld12/4815792fadf119ef41bd)

Before, looking on [Dockerhub](https://hub.docker.com/) for containers you can download

And completing [Docker101](https://github.com/dockersamples/101-tutorial)

Read [this article](https://medium.com/@saschagrunert/demystifying-containers-part-i-kernel-space-2c53d6979504) about Kernel Space

If you are enjoying Docker, and want to learn the next natural progression from here, think about:

- [Kubernetes](/how-to-learn/kubernetes)


How to Learn Docker


Start with a [Tour of Go](https://go.dev/tour/welcome/1), and solve all the challenges

Then just begin reading [Effective Go](https://go.dev/doc/effective_go) and [Go by Example](https://gobyexample.com/)

The above steps were inspired by [Jeff Hodges](https://www.somethingsimilar.com/2013/12/26/code-to-read-when-learning-go/)

I found this [overview](https://www.digitalocean.com/community/tutorial_series/how-to-code-in-go) very useful

I also spent some time reading through the [docs](https://go.dev/doc/) 

At this point, I'd recommend just building and breaking things, specifically:

- Experimenting, breaking and deploying: https://github.com/heroku/go-getting-started
- Make an endpoint to recieve a string, and return the sum of all the characters unicode code-points
- Make a go connect to a containerised database

If the above sounds too intimidating, you can code along your first app [here](https://golang.org/doc/articles/wiki/)

I found it very useful to just read lots and lots of good go code, example code can be found at [compose-cli](https://github.com/docker/compose-cli) or [cli](https://github.com/docker/cli) or just the go [standard library](https://pkg.go.dev/std)

I also found it useful to read [How to Write Go Code](https://go.dev/doc/code)

And I also have heard lots of good things about [learninggo](https://miek.nl/go/)

How to Learn go


Docker is a useful technology to learn before Kubernetes, so I'd start [here](/how-to-learn/docker/)

Firstly, read [this](https://containerjournal.com/topics/container-ecosystems/how-docker-and-kubernetes-work-together)

Next, I'd look at a [cool tutorial](https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/) to help you:
- Manage your first cluster
- Explore clusters
- Deploy clusters

Finally, I'd code along and read [this](https://www.freecodecamp.org/news/learn-kubernetes-in-under-3-hours-a-detailed-guide-to-orchestrating-containers-114ff420e882/)

How to Learn Kubernetes


If you want to learn math for comp sci, or for your own enjoyment I would:

Work through [Khan Academy](https://www.khanacademy.org/math) - where you can pick which age you want to start with.

How to Learn Math


Firstly read an intro article [here](https://martinfowler.com/articles/micro-frontends.html)

Then read how to practically [build them](https://codeburst.io/4-practical-ways-to-build-micro-frontends-4dc4f0b8a921)

Then watch this [talk](https://www.youtube.com/watch?v=ftBc8w-lwmY)

How to Learn Micro-frontends


I firstly started by reading [this article](https://scotch.io/starters/react/getting-started-with-react-2019-edition)

I then read React documentation. React (as of 2022) are re-working their docs, so the beta docs are [here](https://beta.reactjs.org/), or the "current" docs (not in beta) are [here](https://reactjs.org/docs/getting-started.html)

I then worked through the [freeCodeCamp exerises](https://www.freecodecamp.org/learn/front-end-libraries/#react)

From here, I just coded up basic React apps using [create-react-app](https://github.com/facebook/create-react-app#creating-an-app)

So I made a web-app to test solutions to [Einsteins riddle](https://einsteins-riddle.com/)

Or if you need project ideas, you can [look here for inspiration](https://www.freecodecamp.org/learn/front-end-libraries/#front-end-libraries-projects)

If starting to code projects feels too hard, try a [tutorial](https://reactjs.org/tutorial/tutorial.html) first

And I also really enjoyed the [courses on egghead](https://egghead.io/q/react)

I have done my best to keep paid courses away from all "How to Learn" posts, but honourable mention to [Colt Steeles course](https://www.udemy.com/course/modern-react-bootcamp/) which is very valuable. But don't pay more than $25 or so. Udemy is known to have HUGE price fluctuations.

How to Learn React


Read this [article](https://www.valentinog.com/blog/webpack/)

How to Learn Webpack

Discover more about software development best practices and read opinion pieces on the software eco-system.

Developer-Forge

Home


Welcome to Developer-Forge!

At the minute, the site is a little empty.

I plan to keep sharing regular blog posts here, and to update the website in general.

Big things on the way, but finally ready to launch version 1!

I hope the beautiful Icelandic horses were worth the visit ;)

The first post!


I've worked across a few different sectors, teams, tech-stacks *etc* and started to think about the patterns I think great teams follow.

### Linting
To ensure consistency, performance and clarity across a codebase - it's normally linted to some level.
Bonus points if the build system automatically fixes common linting errors.
### Fast, non-fragile pipelines
When you either merge your feature branch, or push into master - you have fast CI/CD pipelines that don't regularly break/hang.
### Automated testing
Normally as part of your pipeline, you have a host of unit and integration tests that run, and place a comment on the Merge Request if appropiate.
### Pre-push checks
For smaller non-test related checks, you may have pre-push checks that ensure your commit message follow a certain pattern/references a ticket *etc*
### Unit tests
Most of the significant helper functions/core part of your codebase has fast, useful unit tests - with edge cases considered - that're updated.
### Warnings flagged on problem files
If you have files that a lot of your codebase relies on, you can automatically email people (seniors?) based on these files being changed.
Just to ensure test scope is correct, or that the solution is in the right file for example.
### Easy to deploy
You can quickly and simply deploy to test on an environment.
### Easy to fiddle the code
You don't have to run 5 different repo's at once - with hard to set-up steps, to start debugging on live/uat/dev.
### Fast builds
Your build system takes less than 1 minute.
### Modular
You have correctly modularised, and seperated out your code.
Whether you use a microservice/microfrontend or similar - your code is clearly split and divided.
Sensible folder structure and file organisation.
### Sensible automations
This depends on the company, but manual repeated tasks are targeted with automations.
I've seen systems that automatically rollback code if logging (front-end or back-end) suddenly spikes on a code release.
I've seen releases get automated to save time.
I've seen kubernetes being used because developers kept getting called out at early hours to ssh onto boxes and restart them.
### Sensible logging
Logging can be an anti-pattern- but sensible logs in the front-end and back-end can also help you triage issues, and understand how many customers are facing errors.
Helps you to see if you're getting "better" or "worse" over time.
### Address technical debt
The team is able to advocate for technical debt to be removed, rather than only ever writing new code.
### Regressions
There are regressions conducted on each release to ensure big items (log in *etc*) aren't broken - either manual or test-automations.
### Enough test environments
You don't have developers tripping over environments, and wiping one anothers code off the env.
Normally looks something like: devtest, uat, preprod and prod.
### Perf testing considered
Huge catch-all, but performance in the front-end and back-end is considered and measured.
### Useful 1:1's to help you grow
There are good and bad 1:1 meetings.
Good one's help you learn, grow as a developer and talk about your progression.
Bad one's aren't worth attending.
### A good way to unblock
If someone gets stuck, there is a recognised way to unblock.
Whether you just slack your Senior/Tech buddy or drop a message in a "help" channel - and someone can either pair with you, or rubber duck you to a solution.
### Good documentation
Documentation is considered, written and edited.
Documentation forms part of the description of "done".
### Version control
Version control is used effectively.
You are able to view old versions and new versions of code on production to understand when issues may have been introduced - like a manifest editor.
### Code re-use libraries
Code re-use is considered, and there are shared code libraries where necessary.
### Test harnesses, mocked scenarios
Mocking can be super fragile, so taken with a grain of salt here.
But scenarios can be mocked in a test harness or storybook - to view different permutations/edge cases.
### Good onboarding
This final step comes about when everything else is done well, but onboarding is considered and criticism taken on-board.
The codebases are painless to set up (containerised?) - and have as much automated as possible.
You're given a tech buddy to ask questions to if you get stuck.


Components of a great software team


I've worked across different high-performing teams.

A selection of these were:
- Serving with the Royal Naval Reserves working with long-serving officers and ratings
- Working at a multi-billion pound software development company (with extremely talented engineers)
- Working freelance with some industry leading individuals

The only thing I've noticed all exceptional people (across multiple fields) do to perfect their craft, is **practice**.

I heard my XO ([Executive officer](https://en.wikipedia.org/wiki/Executive_officer)) one time when deployed with the Navy, mentioned he would rather have $NAME on the ship before he took on any other Royal Naval Reservist.

The only thing $NAME had done, was have multiple deployments under his belt and had spent lots of time on the ship.

# Just do the activity

- To be a good violinist, play the violin more.
- To be a good coder, code more.
- To be a good writer, write more.

This applies to beginners and to people approaching mastery of their craft.

> You'll always hear the same thing said by the very best in every field 'I feel like I'm still learning they'll say. The way you stop fearing faiure is you always assume you have more to learn. Success is about what you get. Craft is what you get to do. <cite>James Clear</cite>

# Nothing new

I don't think I'm saying anything new.

I have heard people say this a thousand times over and over.

- Spend time in the saddle
- Just build
- Practice, practice, practice

But as a beginner, I *hadn't* heard this, and I'm writing this for Kealan in the past, or newbie coders wanting to improve as quickly as they can.

> Work hard. I got tenure a year early. Junior faculty members used to say to me: 'Wow, what's your secret?' I said: 'It's pretty simple. Call me any Friday night in my office at 10 o'clock, and I'll tell you.' <cite>Randy Pausch</cite>

# It's hard, but it works faster

When I first started learning how to code, I thought shadowing, and watching experts would "propell" me faster.

It's helpful to do in moderation, but it's not as effective I believe, than just coding.

Coding myself was way, way harder than watching these expers who just "knew" how to do everything.

But I improved way, way faster - by doing the difficult, arduos work of coding more.

It also has the added benefit of enabling you to see if you enjoy doing the activity.

If you hate coding, and don't want to do it - spending 8hrs a day coding as an Engineer might leave you miserable.

The "least fun" part of coding is when you first start, and have no idea what to do.

If you can get over that hurdle, chances are you can learn to be a great professional Engineer.

> We all want progress. But progress means getting nearer to the place you want to be and if you have taken a wrong turning, then to go forward does not get you any nearer.	
> If you are on the wrong road, progress means doing an about-turn and walking back to the right road; and in that case, the man who turns back soonest is the most progressive man.	
> We have all seen this when we do arithmetic. When I have started a sum the wrong way, the sooner I admit this and go back and start over again, the faster I shall get on.	
> There is nothing progressive about being pigheaded and refusing to admit a mistake.	
> And I think if you look at the present state of the world, it is pretty plain that humanity has been making some big mistakes. We are on the wrong road. And if that is so, we must go back. Going back is the quickest way on. <cite>C.S. Lewis</cite>

# Conclusion

I have written on similar topics to this, you might enjoy:

- [How to get better at coding, even when it's hard](https://www.freecodecamp.org/news/how-to-get-better-at-programming-even-when-its-hard/)
- [My 4 best tips to improve as a developer](https://www.freecodecamp.org/news/how-to-become-a-better-developer/)

Just build


Discussing how people improve as software engineers is something I really enjoy studying, thinking and reading about.

I have written in the past about:

- [How to improve as a developer, even when it's hard](https://www.freecodecamp.org/news/how-to-get-better-at-programming-even-when-its-hard/)
- [My 4 best tips to improve as a developer](https://www.freecodecamp.org/news/how-to-become-a-better-developer/)

I love thinking/reading about questions like:

- How do people progress professionally as engineers?
- How do developers go [from Senior to Staff](https://staffeng.com/) or beyond?
- How do Engineer scale themselves? 

Part of the answer I think, is looking at:

- Compotency Matrices and Career Progression ladders companies put out to explain what they expect in each role.
- Individual opinions from industry experts who have gone from Mid-Level Engineer to CTO (etc)

Trying to look and standardise what totally different companies search for - helps you understand what is valuable in the marketplace.

This has led me to compiling around 70 publicly accessible career matrices from companies around the world, from places like:

- Soundcloud
- Dropbox
- Etsy
- Gov.uk
- Medium
- Khan Academy
- Circle CI
- Monzo
- Patreon
- Financial Times

You can read them all [here](https://github.com/kealanparr/Career-progression-matrices)

I've been spending time looking at areas where I'm strong and looking where I'm weaker too - searching for ways I can grow & improve.

I hope this is of use to you too!

Career Progression Matrices

Amdahl's Law


Bikeshedding is when development teams spend too much time on small items that don't really matter, like the color of the bikeshed in your offices.

Imagine if your development team has a huge project upcoming, and you need to make huge decision about: major architectural direction of the code, the new code principles for this upcoming codebase, how you will test it and release it *etc* - but in this meeting you can't seem to get off minor discussions like whether you will draw up all the technical planning in a PDF or a Markdown file on GitHub. This is a good example of bikeshedding.

Normally bikeshedding happens when people feel overwhelmed by big decisions that seem too difficult, but the "easier" decisions are much simpler to reason around so everyone feels like they can "chip in". This can lead to lots of voices all speaking about small issues they are comfortable enough to talk about, but don't really matter too much.

A healthy solution to bikeshedding is to try and solve the biggest issues first, and the "smaller" issues normally start to sort themselves. You finally planned out that huge project and how you can solve some of the issues? Then you've easily solved the PDF vs Markdown discussion, as PDF didn't work due to needing multiple people contributing so it ended up being a file in GitHub so the developers can push and pull to update it *for example*.

Bikeshedding or the Law of Triviality


Have you ever worked on a software project that is late?

The normal approach from management to solve this, is to throw more developer's on the project to try and deliver it as fast as possible.

Brook's Law states that ["adding manpower to a late software project makes it later"](https://en.wikipedia.org/wiki/Brooks%27s_law#cite_note-2)

The most common way I have seen this happen over and over again is with familiarity with the project.

Let's say you have 2 developers on this late project who are very familiar with the code and the way it works, but just gave bad estimates in the early stages when they were planning.

Now management decide to throw 4 more developers on the project to try and deliver it as quick as possible

Brook's Law


The normal flow of another developer QA'ing your code is that they read the code, raise any issues they see with you or explain why they think the way you've fixed an issue, is the wrong way.

Sometimes when asking questions, they may ask you something you're not sure about.

*But why did we need that class before you deleted it in your merge request?*

"Oh.. I don't know why that class was added in the first place. I tested my work though and we definitely don't need it. It isn't doing anything, and the code works now"

Is that a good enough response? The developer said they've tested their code, and it does now work.

Chesterton's Fence is the perfect application to this situation.

Unless we can understand why something was initially the way it was, we can actually make things worse! Not better!

Maybe that class is only used during certain parts of the year (yes it does nothing now, but when it comes to Christmas and we have the hero banner image on the hompage it now won't work because you deleted the class that appends it!) Or maybe yes it isn't doing anything right now, but it's an important class that in the future (when another codebase release their code next week) will be hugely beneficial to stop your codebase error'ing as the new team has changed the data contract you both have.

If we don't understand *why* something was done, we can't make accurate, data based decision on what to do next.

So if the developer can't answer exactly why the class was first added and the problem it solves, Chestertons Fence teaches us to ask the developer to probe deeper, and not be so hasty in making their changes *even if it does work*.

*NB. I hope I have explained this well enough for you to understand, but the name Chesteron's Fence often has a similar [parable/quote](https://www.goodreads.com/quotes/833466-in-the-matter-of-reforming-things-as-distinct-from-deforming) accompanying it everytime it's explained, so let me also ensure you know it.*

> There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road.  
The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."  
This paradox rests on the most elementary common sense. The gate or fence did not grow there. It was not set up by somnambulists who built it in their sleep. It is highly improbable that it was put there by escaped lunatics who were for some reason loose in the street. Some person had some reason for thinking it would be a good thing for somebody. And until we know what the reason was, we really cannot judge whether the reason was reasonable. It is extremely probable that we have overlooked some whole aspect of the question, if something set up by human beings like ourselves seems to be entirely meaningless and mysterious. <cite>G.K. Chesterton</cite>

Chesterton's Fence


> Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. <cite>Melvin E. Conway</cite>

Conway's Law states that technical teams will produce code and architecture that mirrors the companies communication channels/organisation of teams.

For example, if you work in a large 200 person team, with rather disjointed communication mechanisms between all the developers, the code will look something like a huge monolith codebase with random different parts communicating in disjointed ways, with little consistency.

Conway's Law is commonly used as a justification for small teams, that can help promote a more modular, seperated codebase.

Conway's Law

De-Morgan's Law


Demeter's Law states an object should never know about the internal details of other objects. It's been designed to promote loose coupling in software architecture.

It's often [summarised](https://en.wikipedia.org/wiki/Law_of_Demeter#:~:text=The%20Law%20of%20Demeter%20(LoD,specific%20case%20of%20loose%20coupling.) like so:

*The below description uses the word unit- but this can essentially mean function/classs/module etc*

-  Each unit should only have limited knowledge about other units that are closely related to itself (*example* don't have different, random parts of the codebase coupled to one another)
- Each unit should only talk to it's "friends", not strangers
- Only talk to your immeadiate friends

Friends in this example just relates to how close the units are in similarity. If you have a class called `Engine` tightly coupled to `Food` - this is a big red flag, those two words semantically don't fit "together"

By following Demeter's Law you will ensure the code you create will be more maintainable and adaptable, as your code is "composed" of lots of independent units, that you can change, without changing huge parts of your code that other units rely on.

Demeter's Law or the Principle of Least Knowledge


Gall's Law states that all complex systems that work, evolved from simpler systems that worked - and were improved over time.

If you need to construct something difficult with code - it will have hundreds of dependencies, a huge sprawling eco-system of hard-to-code features and need to be as performant as it possibly be, then start with something simple.

Make a much simpler [minimal viable product (MVP)](https://en.wikipedia.org/wiki/Minimum_viable_product), test your assumptions and start to improve incrementally to get it where it needs to be.

I have taken part in a project that needed a huge rewrite (millions of lines of code we're talking) and I directly observed Gall's Law. Slowly, more and more complexity was added to a overly simplistic application- to the point where it started to resemble what we needed.

A few months down the line, and a lot of hard-work later it was in the final state we had in mind- from a small working system, to a big, working system.

Gall's Law


Hofstadter’s law is best explained [as](https://en.wikipedia.org/wiki/Hofstadter%27s_law):

*It always takes longer than you expect, even when you take into account Hofstadter's Law*

In software application, it normally means software estimates are always too small, *even* when you keep in mind Hofstadter’s law and add some extra time to the estimate!

There is a huge amount of software practices/thinking to try and get estimates to be much closer, one of the main ones being to estimate work in **effort** not **time**.

To know exactly how long something will take is very difficult, and is more often than not a guess or guideline and nothing more.

But to estimate in **effort** is often used as you can break it down more discretely into (for example): easy work, medium difficult or hard work.

Hofstadter’s Law


The Hollywood Principle refers to the often repeated phrase in pop-culture "Don't call us, we'll call you"

There are a huge amount of applications to this rule as it's quite general, but the often cited example is:

In any framework/library there are certain function that you shouldn't call yourself.

In React for example, you don't need to ever call `componentDidMount()` as it will be called for you.

At the end of the constructor you don't need to work out how to call this function, it will be called for you, `componentDidMount` is saying "Don't call me, I will call you when I'm ready." 

This is true for so many other frameworks/libraries

- In Angular, you don't need to call `ngOnDestroy()` it will be called for you in the lifecyle
- In Vue, you don't need to call `beforeCreate()` it will be called for you in the lifecyle

By having these life-cycle methods that get called for you at pre-determined times, the schedule and flow of your app is simplified significantly.


Hollywood Principle

Hyrum's Law


*Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know*

Users are more familiar with how everyone is making websites.

Small, assumptions are always present when they use your website.

- A left facing arrow will take them back in their navigation history
- To read more content, it's generally done by scrolling down (not up *e.g.*)
- Underlined words are often hyper links and are clickable
- Green is often associated with upvotes/likes and red is downvotes/dislikes - not the other way around

By following the flow you see and expect on other websites - on the websites you create, you will make users of your site much happier and ensure using it is intuitive.

Jakob's Law

Kerchkhoffs's Law


*Premature optimization is the root of all evil (or at least most of it) in programming*  
*Donald Knuth*

When you make an application, it makes sense to want to ensure it's fast.

No-one wants to sit on your website pages watching a loading page inch along.

So it's a good idea to plan in performance testing (perf testing) and ensure you can handle an increased amount of users right?

Sure! Perf testing is vitally important... but you can do it too early.

If your small side project is still buggy, doesn't work fully yet and is still in development. It probably isn't the time to performance test.

But why? You may end up locking yourself into weird or un-intuitive design decisions because you think it's necessary for your app to be fast.

Normally what happens in the software developemnt lifecycle, is developers: *make it work, make it right, make it fast* (attributed to Kent Beck).

Meaning developers: make the application work first. Then they add comments, clean up any weird hacks they did, ensure it's consistent and fix any code smells or issues they see second. Then only thirdly, make it fast.

This is generally agreed by most developers to be the best way to develop software (there are always exceptions!)

Knuth's Law


Linus's Law states that: *given enough eyeballs, all bugs are shallow*

By shallow here, we mean *found*. If enough eyes look over a code change, eventually all code issues will be found and fixed.

The law was [named in honour of Linus Torvalds](https://en.wikipedia.org/wiki/Linus%27s_law), who is famous for creating the open-source Linux kernel.

The Linux kernel has around [27.8 million lines of code](https://www.theregister.com/2020/01/06/linux_2020_kernel_systemd_code/#:~:text=The%20Linux%20kernel%20has%20around,by%20Michael%20Larabel%20at%20Phoronix.) and by open-sourcing it (and allowing anyone to read it!) the aim is that all bugs and issues will be seen and fixed.

If you have ever been through code review of a large piece of work, sometimes something very obvious to someone else, was just totally forgotten by you. If we keep this trend going and allow hundreds of eyes to review, we stand a good chance of working out any issues asserts Linus's Law.

Linus's Law


Moor's Law is an observation, that the number of transistors on processors double every two years, 

Moore's Law refers to Moore's perception that the number of transistors on a microchip doubles every two years, though the cost of computers is halved. Moore's Law states that we can expect the speed and capability of our computers to increase every couple of years, and we will pay less for them. Another tenet of Moore's Law asserts that this growth is exponential.

Moor's Law


Murphys Law is a simple law that states "anything that can go wrong, *will* go wrong"

Generally, in software it applies to unexpected bad luck that seems to keep cropping up.

There are so many random events that sometimes can't be forseen and planned for in life, let alone the software development lifecycle, and Murphy's Law rather pessimistically advises us to get ready for anything that can go wrong, to do so.

Murphys Law


Norvig's Law states ["Any technology that surpasses 50% penetration will never double again"](https://norvig.com/norvigs-law.html)

Oftentimes, in rapid growth items like software adoption or stock prices, people excitedly report "it grew by 50%!"

If (for example) the adoption of the React JavaScript library in the workplace has reached 50% - it will never double again.

It's a simple mathmetical statement - it can't double past 50% again.

This law does depends what you measure, as sometimes, something can double multiple times past 50% growth (like a stock price).

But for something like software adoption, Norvig's law is absolute!

Norvig's Law


The Pareto Principle is [simply described as](https://en.wikipedia.org/wiki/Pareto_principle) 80% of the results, comes from 20% of the effort. The other 20% of the effort comes from 80% of the effort.

Vilfredo Pareto was the person who discovered this, when he realised that 80% of all property in Italy is owned by 20% of the population. He theorised that this rule would carry across multiple other fields.

The common application is business' being picky in what they focus on, and spend time working on. 80% of their profits will come from 20% effort *spent in the right thing*. The other 80% of their effort will only result in 20% of their profit.

Or an application for a solo software developer is, be careful what you work on, as you only need to spend 20% of your effort working on the right, high-impact job/activity for the majority of your success/achievements. Hard-work isn't all equal, and some hard-work can leave you no-better off than when you started. Or maybe even worse!

Pareto's Principle or the 80/20 Rule


The Peter Principle is a concept in management that people rise to their ["maximum level of incompetence"](https://en.wikipedia.org/wiki/Peter_principle), essentially meaning people get promoted to the point where they are useless/poor at their job.

How does this come about?

Generally speaking, you receive promotions by being excellent in your current role. Then, as a reward you get promoted to a new role. 

But there's no promises you might be good at this new role. Oftentimes, it will have very different skills required from the previous role you had, and you might not be good at it!

Or if you are good, maybe the next promotion puts you in an even more senior position, where *these* skills are vastly different and now you're rubbish!

Eventually, the theory is that everyone hits their ["Peter Plateau"] (https://en.wikipedia.org/wiki/Peter_principle) where they won't be promoted again, as they aren't performing well anymore.

The Peter Principle has a lot of interesting research online, and is interesting to read different theorists all discuss it online.

Don't let the Peter Principle scare you from ever getting promoted, just be aware of each new skill you need to learn for each new role, and be concious being constantly promoted upwards isn't a sure sign of success. Sometimes you may be at "level" you most enjoy and being promoted anymore is just not enjoyable for you :)

Peter Principle


Postel's Law or The Robustness Principle, is [simply defined](https://en.wikipedia.org/wiki/Robustness_principle) as "be conservative in what you send, be liberal in what you accept"

The application is, whenever machines need to talk to one-another, that they should accept messages that might not be perfectly formatted but the intention/message is clear, but should be very rigid in what they send.

If you send a message, you should ensure you conform completely to the specification/standards that governs your message format (JSON for example) but be flexible when receiving messages and ensure you don't crash/error if the input is malformed to you.

Postel's Law or The Robustness Principle


Wirth's Law is the idea that software [is getting slower faster than hardware is getting faster](https://en.wikipedia.org/wiki/Wirth%27s_law).

Martin Reiser was the first to say something similar, where he [said](https://en.wikipedia.org/wiki/Wirth%27s_law) in the preface of a book "The hope is that the progress in hardware will cure all software ills. However, a critical observer may observe that software manages to outgrow hardware in size and sluggishness."

Wirth's Law

- [Bikeshedding or the Law of Triviality](/principles/bikeshedding/)
- [Brook's](/principles/brooks/)
- [Chesterton's Fence](/principles/chestertons-fence/)
- [Conway's](/principles/conways/)

- [Demeter's Law or the Principle of Least Knowledge](/principles/demeters/)
- [Gall's](/principles/galls/)
- [Hofstadter's](/principles/hofstadters/)
- [Hollywood Principle](/principles/hollywood/)

- [Jakob's](/principles/jakobs/)

- [Knuth's](/principles/knuths/)
- [Linus's](/principles/linus/)

- [Murphy's](/principles/murphys/)
- [Norvig's](/principles/norvigs/)
- [Pareto's Principle or the 80/20 Rule](/principles/pareto/)
- [Peter Principle](/principles/peter/)
- [Postel's](/principles/postels/)
- [Wirth's](/principles/wirths/)

The way you develop & think about software is influenced by the principles you're aware of. 

Software Principles


- [How to speak - Patrick Winston (MIT OpenCourse)](/tech-talks/how-to-speak)



Condensed Tech-Talks


**How to Speak - Patrick Winston (MIT OpenCourse)**

**Full talk:** https://www.youtube.com/watch?v=Unzc731iCUY

**Length** 60 minutes

--------------------------

# Intro

1. "The Uniform Code of Military Justice specifies court martial for any officer who sends a soldier into battle without a weapon. There ought to be a similar protection for students because students shouldn't go out into life without the ability to communicate"

2. "That's because your success in life will be determined largely by your ability to speak your ability to write, and the quality of your ideas, **in that order**"

3. Our metric for good communication is a measure of "of how much knowledge you have, how much you practice with that knowledge, and your inherent talent, and notice that the [talent is the least important part]."

# Structure to a good talk

1. You want to tell people what they're going to know at the end of the hour that they didn't know at the beginning of the hour. It's an empowerment promise. It's the reason for being here. 
	- Express some passion about what you're talking about & provide something of value the listener will receive.


2. It's a good idea to cycle on the subject (and repeat the main topic a few times)
	- Why? one of which is, at any given moment, about 20% of you will be fogged out no matter what the lecture is. So if you want to ensure that the probability that everybody gets it is high, you need to say it three times. 


3. Build a fence around your idea so that it's not confused with somebody else's idea.


4. Give peoplew who start to daydream a chance to get back onto your talk
	- You can do this by
		- Adding numbers to your talk and seperating the talk into discrete idea 1. First idea 2. Second idea 3. Etc
		- Or by asking questions to the audience (not too hard or no-one will speak, not too easy or people feel silly answering)


5. Don't speak after a big meal, or in a dark room (or your audience will fall asleep)
	- "Oh, they might reply, people will see the slides better if we turn the lights off, and then I reply, it's extremely hard to see slides through closed eyelids"


6. Case out the place where you will speak to prepare for how it will affect your talk, so you can prepare for any weirdness. This also helps you pick a room not too big, or too small for audience comfort.


7. Speakers tend towards too many slides and too many words. Have bare slides and talk more - don't read off your slides

8. It's important to 1) Have a clear vision 2) Show that you've done something
	- If you went to a talk with someone who had no achievement in the talk they were presenting, or a clear vision of their talk - it's a fast-track to a boring, useless talk
		- You have about 5 minutes to prove you're succesful in this field and you have a vision. If you take longer, it's similar to not having those things


9. Do your best to package your ideas well so they are listened to, respected and value derived from them
- "[I was at a party with the late Julia Child], and as the evening wore on, more and more people would come up and ask Julia to autograph something or express a feeling that she had changed their life. And it just happened over and over again. So eventually, I turned to Julia, and I said, Ms. Child, is it fun to be famous? And she thought about it for a second. And she said, you get used to it. But you know what occured to me? You never get used to being ignored."
- "Your ideas are like your children. And you don't want them to go into the world in rags. So what you want to do is to be sure that you have these techniques, these mechanisms, these thoughts about how to present ideas that you have so that they're recognized for the value that is in them. So that's why it's a legitimate thing to concern yourself with packaging. Now, how do you get remembered?"
  - Symbols that are associated to your idea (visually tying your idea to a symbol is a strong way to get it recognised)
  - Slogan (a phrase to summarise the work)
  - Surprise (suprisingly, you don't need 10 examples, you just need one good example and to repeat it)
  - Salient Idea (an idea from your talk that sticks out - one prominent key takeaway)
  - Story (the narrative: how you did it, how it works, why it's important)