Tech Advice

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

How to Complete a Side Project and Turn it into a business

Link

  1. Small scope
  2. Don’t compete on features with big players
  3. Don’t work alone on the project
  4. Don’t keep the idea secret
  5. Choose boring technology

Kick Ass Ecommerce Checklist

  • Mobile First
  • Super Fast
  • Scalable
  • A/B Testing
  • Personalized
  • Live Content

(No page view is the same)

Why I like Python

why-I-love-python
Why I love Python and compiled languages suck

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

Why developers write tests:

  • 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

circle of development hell

Cutting through the job ads crap

development jobs funny read

The best explanation of the car engine I’ve ever seen

best explanation of the car engine I’ve ever seen

Doing something Big?

  1. Set out to prove yourself wrong
  2. Create a team that gets stuff done
  3. Communicate openly and frequently

On Clients

client-and-code-quality

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.

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

Leave a Comment

Your email address will not be published. Required fields are marked *