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 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

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


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 one you think I should read, please contact me via this site and tell me, I would love to add a good one to my list :)

Books Read


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

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


> 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

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

Developer-Forge

Home


*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


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!

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

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

- [Jakob's](/jakobs/)

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

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

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

Software Principles

This is still in progress :)

Condensed Tech-Talks


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."