Freek.dev

Read more [youtu.be]

It’s the start of a new fiscal year. Strategy season. That time when all the grand ideas come out and everyone is still hopefull.

Over the years, I’ve settled into a structure that helps me define projects that not only link to the strategy above but also looks at my own team’s enviroment, I thought I’d share it here.

Read more [frederickvanbrabant.com]

After more than 9 years working with Laravel—leading a dev team and architecting solutions—I still sometimes feel like I’m not doing enough.

Read more [www.moisis.dev]

Many of the most effective people I’ve worked with also do the most metacognition, i.e., reflecting on their own (and their team’s) work and thought processes, and figuring out how to improve them.

Read more [www.benkuhn.net]

An important post by Nico.

Read more [nicoverbruggen.be]

In this excellent, humanly written blog post, Laracasts founder Jeffrey Way offers some good tips for applying at any company.

Read more [laracasts.com]

Tighten employees share encouragement for anyone struggling through the pandemic.

Read more [tighten.co]

Here are some strategies Toon Daelman uses in discussions.

Read more [engagor.github.io]

This timeless talk by Matt Stauffer given at Laracon EU 2015 is one of the very best I ever saw.

Read more

James Brooks recently started a podcast on mental health. In the second episode Matt Stauffer was interviewed.

This week I’m speaking to Matt Stauffer. Matt is a partner at the web agency Tighten, developer, teacher, podcaster and author. Matt and I speak about his experiences with anxiety and depression, being a great employer and other things!

Read more [happy-dev.transistor.fm]

Don't try to manage your colleagues too much.

Employees want to be managed by people who empower them, not manage every bit of their day. The better you get at hitting the right balance between oversight and autonomy, the more likely you are to win long-term fans who will advocate for you as your career progresses.

Read more [forge.medium.com]

Mike Veerman points out that managers that are not making decisions are lazy.

Lazy management means not choosing. It’s only paying lip service. When we put quality first, together with security and performance and everything else, we’re not doing our job. We’re postponing the inevitable in the hope the monster goes away.

Read more [www.mikeveerman.be]

On Basecamp's Signal v. Noise blog Claire Lew warns about the dangers of wanting to be nice all the time.

Now I’m not advocating for us to be mean. Disrespectful or dismissive leaders help no one. Rather, I’m calling for us as leaders to loosen our grip on “being nice.” To stop wanting our team to like us all the time. To let go of the expectation that every single interaction with our team should feel good. ... When we’re preoccupied with seeming popular instead of fair, when we optimize for pleasant conversations instead of honest ones — we hurt our teams.

Read more [m.signalvnoise.com]

Project failures is a WordPress blog with horror stories of project that have terribly gone wrong. I recently stumbled across this particularly juicy story.

A few years ago, I was hired to work as a consultant on a software project for a large French tech company. What I have witnessed there is beyond everything I could possibly have imagined in terms of software engineering. Far more serious than just a lack of professional competence was the utmost contempt for human dignity which at some point made me compare the whole experience to (what I imagine can be) jail. What I relate here is a selected list of topics that should illustrate my point, but check out by yourself.

https://projectfailures.wordpress.com/2008/06/24/project-from-hell/

Read more

Marty Cagan, who held jobs at eBay, AOL, Netscape and HP, describes the most important differences between good and bad product teams.

What I’ve learned is that there is a profound difference between how the very best product companies create technology products, and the rest. And I don’t mean minor differences. Everything from how the leaders behave, to the level of empowerment of teams, to how the organization thinks about funding, staffing and producing products, down to how product, design and engineering collaborate to discover effective solutions for their customers.

http://svpg.com/good-product-team-bad-product-team/

Read more

On the Tighten blog Samatha Geitz sums up the benefits of giving developers one day of "free" time a week.

About a year ago, Tighten officially implemented a "20% time" policy for its developers. This means that, on any given week, we only bill our clients for 32 hours of developer work; for the other 8 hours, developers can work on whatever projects they’d like to (as long as they can readily come up with an explanation of how it benefits the company in some way.) ... Here are some reasons that you may want to consider experimenting with a policy like this

https://blog.tighten.co/give-your-developers-20-percent-time

Read more

Bill Jordan wrote an absolutely amazing piece on the things he learned in the twenty-eight years he worked in the software industry. There are so many good insights that I can nearly quote the entire article.

Here are some of the things that resonated with me:

Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. These kinds of high performers are actually low performers when when TCO is factored in.

Encourage developers to improve the application while working on their projects. Examples of improvements are creating reusable objects out of copypasta code and breaking up large objects that are difficult to maintain into smaller objects that individually are easier to reason about. Improve the database schema even if it hurts in the short term. Delete old and unused code. With the benefit of hindsight update the user interface to improve user experience — sometimes even just changing a word or two makes a big difference.

When continual improvement is part of the DNA of your team you’ll be amazed with the results, but give those results some time to become apparent — it won’t happen overnight. It also means management will need to recognize that things will take more time since developers will be working on their primary project while simultaneously making incremental improvements.

Be sure to read the entire post: https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450#.1j7a7qos3

Read more

Yiannis Konstantakopoulos, a designer at Porcupine Colors, wrote an excellent piece on workaholism.

Workaholism is often confused with hard work. Some people who work on the Web seem not only to disregard its dangers, but to actively promote it. They see it as a badge of honor — but is it really? On the contrary, it’s a serious issue that can damage Web teams.

Before we get started, let’s make one thing clear: A “workaholic” is someone who is addicted to work, someone who is out of balance and out of control. Their addiction can make them work for 12, 14 or even more hours a day, every day. No weekends, no vacations, just work. Soon, they neglect their family, friends, health, sometimes damaging them all irrevocably.

https://medium.com/@porcupine/dealing-with-workaholism-on-web-teams-d6e156d82a08#.jyzawevsb

Read more

This Friday the PHP Benelux Conference will kick off. It has an excellent line up and I'll probably blog about the sessions I will see there.

Last year the keynote of the conference was given by Yitzchok Willroth aka Coderabbi. He emphasizes on the power of the community. It was a great talk, I even dare to use the word "inspirational". In the weeks and months after his talk numerous PHP user groups were formed in my home country, Belgium. I believe this was no coincidence.

A few days ago a video of this talk (given at another conference) was published. You can watch it below.

Read more

Here are the stages:

1. Adopt personally
2. Find the totem
3. Repetitively broadcast

I had to learn about each stage separately. Each one contains activities that my 18-year-old self would never have believed were necessary.

Read more