Freek.dev

An excellent talk by Eryn O’Neil that underlines the fact that the code we write should be as humane, warm, emphatic and thoughtful as we ourselves need to be in real-life.

Read more

Iain Poulson wrote a good article on public speaking.

"But Speaking Is For Experts" This is a common fallacy that needs to be dispelled if you are to get up and start speaking. Conference speakers are not necessarily experts that know more than you. They are just people who have stood up! ... Anyone can do a talk, regardless of your background and skills – you have something to offer.

https://deliciousbrains.com/stop-worrying-love-giving-a-talk/

Read more

Gregory Brown wrote an excellent article on how you can grow as a programmer.

Do you know what the difference between competence and proficiency is? ... Competence means having enough experience and knowledge to get stuff done; proficiency involves knowing why you are doing something in a certain way, and how it fits into the big picture. In other words, a proficient practitioner is always a competent practitioner, but the opposite may not be true.

https://www.oreilly.com/ideas/the-traits-of-a-proficient-programmer

Read more

Eric L. Barnes asked this question to people with several backgrounds.

I love questions that can’t be answered with a simple yes or no. One question that I have been thinking about recently is, just what does it take to be a great developer?

I came up with tons of answers but felt like mine are all through my own lens, so I decided to reach out to a few people from different walks of life and just ask them. What follows is the answer by each person and their profession so you can compare and contrast.

Read more

Michael Bromley on his blog:

There is an implicit agreement which needs to be understood by both consumers and creators of FOSS projects¹. It goes something like this:

• I agree to provide you with some free code which solves your problem.
• I recognize that in doing so, I have taken on a small portion of responsibility to you as a user of my code.
• I agree to try to help you if you have difficulty in using my code.
• I agree to try to fix bugs that you find in my code.
• Crucially, you agree that I, in acting without remuneration, am free to assign priority to the above points as I see fit.

The last point is the reason why I haven’t fixed your issue yet.

As a package consumer you should be grateful for the free code you're given. Keep in mind that when you use someone else's code, you are responsible for that code as well. If a package maintainer solves an issue for you that's great. If he or she doesn't, than that's your problem, not the maintainer's. You can always submit a PR with a fix. And if the fix or feature doesn't get accepted you can always maintain your own fork.

For our own packages we try to respond to every single issue in a timely manner. The users of our packages are generally very friendly and helpful. There's only one instance when things went sour. I do make a point of thanking everybody who takes the time to submit a PR. It's a small thing but I do believe it helps creating a positive vibe on our GitHub repo's.

Read more

Philip Walton, an engineer at Google, wrote a wonderful article that every developer should read. He talks about front-end engineers, but most tips are applicable to back-end engineers as well. A few quotes:

Taking the time to figure out why your hack works may seem costly now, but I promise it’ll save you time in the future. Having a fuller understanding of the systems you’re working within will mean less guess-and-check work going forward.

Solving problems on your own is a great way to learn, but if that’s all you ever do, you’ll plateau pretty quickly. Reading other people’s code opens your mind to new ways of doing things.

In my experience, writing, giving talks, and creating demos has been one of the best ways to force myself to dive in and fully understand something, inside and out. Even if no one ever reads what you write, the process of doing it is more than worth it.

Read more

Developers can appear very unproductive at times, sitting staring at the screen with our headphones on and very little in the way of keyboard clackety-tap. This however is when we are doing our thinking, when we are building up, adding to and rearranging the mental model of how our code will work. This is the biggest and hardest part of development.

Imagine how it feels to have that interrupted at random by a telephone call or somebody walking over to talk to you. It’s horrible.

Read more