Distance yourself from people who:
- Speak poorly of others
- Have problems for every solution
- Make you feel bad about yourself
- Always feel entitled
- Blame others for losing
- Take more than give
- Enjoy complaining
- Cheat or lie
- Bully or troll
- Nitpick as a hobby
Reasons for more than 1 k8s cluster:
- One big cluster for utilization, in-cluster communication, and reduced overhead
- Many Small clusters for isolation (and cost control isolation), reduced blast radius, and less challenges around scaling
https://twitter.com/firasd/status/971473606654873601
https://twitter.com/adamjogrady/status/952784870081572864
https://twitter.com/_ericelliott/status/905129710941855744
When companies talk about burn rates, know two things are burning: Money & people. One you’re burning up, one you’re burning out – Jason Fried
When it comes to configuration management, configure the minimum is a good rule of thumb. Keep it minimal let the defaults run – Me
https://twitter.com/dhh/status/907306147559890944
Recommendations on all things:
- Don’t reinvent the wheel
- Start simple and iterate
How to Complete a Side Project and Turn it into a business
- Small scope
- Don’t compete on features with big players
- Don’t work alone on the project
- Don’t keep the idea secret
- Choose boring technology
Kick Ass Ecommerce Checklist
- Mobile First
- Super Fast
- Scalable
- A/B Testing
- Personalized
- Live Content
(No page view is the same)
On Experience
If I do a job in 30 minutes it’s because I spent 10 years learning how to do that well in 30 minutes. You owe me for the years, not the minutes.
Why I like Python
https://twitter.com/dhh/status/834146806594433025
Implying that you should be testing what they will be doing in real life. Not this bubble sort which has been solved and there is a standard library for. Or going for an interview for a carpenters position and them asking you to create a table with just a hammer and no use of the shop tools.
Quizes and tests are not always the best option. Sometimes just looking at their work (what they have done) and asking questions about it is good.
Simple things are good
As I’ve leveled up as a dev, I’ve also noticed that language-bashing is basically saying out loud "My experience is very limited." – Annalee B-8
- Prevent Regressions
- Improve Design
- Enable later refactoring
- Document Behaviour
Being proud of 100% test coverage is like being proud of reading every word in the newspaper. Some are more important than others. – Kent Beck
Being a good senior developer is easy:
- Don’t tell, ask
- Don’t rewrite; pair and refactor
- Don’t sneer, encourage
- Be kind
If you don’t actively fight for simplicity in software, complexity will win. …and it will suck. – Henrik Joretag
On Advertising: ‘Everyone hates advertising till they lose their cat’ – Dave Droga
Entrepreneur Quotes
Dear Entrepreneur, Rejection is re-direction. But never accept NO from someone who doesn’t have the authority to say YES. – Soko Analyst
Funny Pictures
Development hell
Cutting through the job ads crap
The best explanation of the car engine I’ve ever seen
best explanation of the car engine I’ve ever seen
Doing something Big?
- Set out to prove yourself wrong
- Create a team that gets stuff done
- Communicate openly and frequently
On Clients
C#
C# Exception handling and debugging great article
Developer Career Path
A great presentation on quantifying what junior, mid level and senior developers really are. Not just the titles. Also showing that the path does not have to force you to become a manager. Showing you how to become a software engineering lead.
https://www.youtube.com/watch?v=yIPbE7BssOs&app=desktop
http://www.onbeing.org/blog/the-disease-of-being-busy/
Per on Working with Companies
For the past 6 years, I’ve consulted on software projects with companies ranging in size from the biggest enterprises to startups.
I’d like to share some things I’ve learned.
Since we work side by side with our clients’ engineering teams, I get to observe many different types of organization (or lack thereof). Every client and project is unique, but have some things in common.
What many of them share is this: They have great engineers, but somehow their engineering teams are performing under, or well under, their potential.
There are three main reasons I see this happen.
Reason one teams fail: A lack of trust.
If you don’t trust the people you hired to do their jobs, you are missing out on most of their potential.
Often, mistrust is grounded in fear – that people will slack off, go down thew wrong path, or run over budget. This is a fallacy. Almost everyone wants to do a good job.
Unnecessary bureaucracy slows innovation and kills motivation. Given autonomy and freedom to execute, people are motivated and feel empowered to make decisions.
To succeed, people need to know where you want them to go, not how to get there – which brings us to the next point.
Reason two teams fail: A lack of communication.
Lack of communication between team members, between teams, and from the people with a vision to the people with the know-how to make it happen is a recipe for failed projects.
It’s worth noting that a culture of mistrust often leads to noncommunicating teams. The solution is (shockingly!) to get together and talk. Don’t silo teams but treat dependent teams as part of the same large team.
Start with a conversation, figure out who needs to regularly talk to whom, and use tools like Jira and Zeplin to surface information previously stuck on people’s private drives.
Reason three teams fail: Too little or too much process.
An engineering process out of harmony with the team’s needs is a productivity killer.
The point of process is to enhance team communication and help the team keep the quality of product and code consistently high. Period.
Goals like reporting on timelines, demoing progress, and holding the team accountable to targets can all be functions of any lightweight tool the team uses to track work, but must not be used as reasons to control how the team works.
I find that in a culture of trust, where goals are clearly communicated, teams with a code review process, an issue tracker, and a weekly retrospective will outperform any dogmatic Agile team run by a “scrum master”.
"Simple models often outperform complex models in complex situations" –
Andrew Heldane
Why do we trust tests? – Mark Seemann
- They are easy to review
- We have seen them fail
The tweak muscle yearns to be flexed!
That’s a perfectly natural reaction. Certainly there’s always room for improvement. And there is always more to explore. Always.
Always is the problem.
Going from 99% to 100% is expensive. I’d rather we spend that 1% going from 0% nothing to 1% something (or 50% on the fence to 51% conviction) on something else.
Rob Pike’s 5 Rules of Programming
- You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.
- Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.
- Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.)
- Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.
- Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming
Source Rob Pike’s 5 Rules of Programming
Good Error Messages
Should give info about:
- Who caused an error?
- What happened and why?
- When will it be fixed?
- How can the user respond to the error?
Source: Online of not – Fastly Outage