Had to print out @jasonfried's tweet: https://t.co/vJALXrvsG7 pic.twitter.com/imIL6AjIHX
— Firas Durri (@firasd) March 7, 2018
every library should have a good science fiction and fantasy section pic.twitter.com/Yzp9VtezJk
— Published Author Adam O'Grady (@adamjogrady) January 15, 2018
Most effective ways to reduce bugs:
1 Code review
2 TDD
3 Spec/design review
4 Pair programming
5 Manual (human) testing#code #tdd— Eric Elliott (@_ericelliott) September 5, 2017
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
Quickest way to spot an enterprisey software company? They can't just sell products, they must sell "solutions".
— DHH (@dhh) September 11, 2017
Recommendations to get Started with Autoremediation
- 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
Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles.
— DHH (@dhh) February 21, 2017
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.
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.