Posts tagged with learning

How to become a great engineer

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.
Be sure to read the full article here: http://philipwalton.com/articles/how-to-become-a-great-front-end-engineer/

Read more

Continuous learning

Education. In a fast-changing environment such as the web industry, education is the single most important thing to survive. The things I learned about PHP when I started doing PHP 17 years ago would not even get me a job anymore today. Where traditional jobs mostly require just the standard education with a short course every once in a while, the web industry is vastly different.

...

In this article I’ll go into some strategies and some ways to keep the knowledge of you and your team current.

https://dutchweballiance.nl/techblog/continuous-learning/

Read more

Join thousands of developers

Every two weeks, I share practical tips, tutorials, and behind-the-scenes insights from maintaining 300+ open source packages.

No spam. Unsubscribe anytime. You can also follow me on X.

Learn React.js in just a couple of afternoons

Wes Bos released a series of videos on React.js.

Together, we will build “Catch of the Day” — a real-time app for a trendy seafood market where price and quantity available are variable and can change at a moments notice. We will build a menu, an order form, and an inventory management area where authorized users can immediately update product details.
Wes has released some really learning resources on, amongst others the terminal, sublime. A while ago he also appeared on Full Stack Radio. I'm pretty sure his new batch of videos will be top notch!

Read more

Building a basic router

There is always value in learning about the internals of the frameworks and libraries we use. It allows for a deeper understanding of the problem being solved and appreciation of the work that has gone into these projects.

So today I will be building a basic router to explore this fundamental part of even the smallest framework. The idea is not to create something complete or production-ready but rather the minimum set of features needed to be considered a router.

https://medium.com/@dylanbr/building-a-basic-router-b43c17361f8b

Read more

Let the magic die

The venerable Uncle Bob wrote some thoughts on picking a framework:

Before you commit to a framework, make sure you could write it. Do this by actually writing something simple that does the basics that you need. Make sure the magic all goes away. And then look at the framework again. Is it worth it? Can you live without it?
http://blog.8thlight.com/uncle-bob/2015/08/06/let-the-magic-die.html

I've quoted the end of the post, but you should read it in full, it's worth it. I agree with most things in the article. You should constantly learn stuff and try making the basic functionality yourself to get a better understanding of how things work.

Though there is certainly truth to it I don't fully agree with: "Before you commit to a framework, make sure you could write it." It's good advice when you're very experienced or if you have time enough to investigate lots of stuff. For most people this isn't that case.

When starting out writing PHP almost 10 years ago I made my own little framework because I didn't know any better. I thought I was doing fine. Looking back at the projects I made with it, I'd say they're all horrible.

Zend Framework 1 came out. It sped up my development because I didn't have to do every little thing myself. Did I understand everything ZF was doing behind the screens? Certainly not. Did ZF create value for me right from the start? Hell yes. While using the framework on various projects I read about how it worked and learned a lot about PHP. I thought I was doing fine. Looking back at the projects I made with it, I'd say they're all horrible.

A few years ago I read some positive articles about Laravel. I really liked the syntax and the feel of things. Sure, it was a gamble to choose a framework I didn't know but it worked out really well. While using Laravel I learned, thanks to some excellent learning resources, lots of things on design patterns and best practices.

It's certainly possible that, in the coming years, Laravel will be replaced by a new shiny framework. Maybe I'll then write a post on Laravel saying "I thought I was doing fine. Looking back at the projects I made with it, I'd say they're all horrible." .

Generally speaking I think the following applies to most frameworks and most programming languages:

  1. When you see a framework / language that feels good to you, read a bit a about it.
  2. If you still feel good about it, use it on a small project
  3. If after that project you still feel good about it, use it again, maybe on a bigger project. Learn a bit more how framework and language works.
  4. Repeat steps 2 and 3 until you find yourself at step 1 again.
The most important part is the learning in step 3. If you don't do this you'll be a programming cowboy forever.

Of course all of this depends on context. I would never pick a technology unknown to me when starting to work on a large and expensive task. Learn and experiment when working on small projects. Use what you have learned on the big ones.

Read more

Learn by listening to these podcasts

The past few months, I've been trying out some podcasts. Listening to them is an easy way to learn about and stay in touch with the sprawling range of topics that could interest a developer. These are my favourites:

The Laravel Podcast

The Laravel podcast focusses on Laravel (of course) and the latests trends in the PHP world. The podcast is hosted by Matt Stauffer. Jeffrey Way and Taylor Otwell are regular guests. Recently the format of the show was changed: episodes are now around 30 minutes in length, which I think is great.

Listen in iTunes Follow on Twitter

Full Stack Radio

This podcast isn't narrowly focused on one subject. In each episode Adam Watham interviews one guest. Topics range from product design to system administration and everything in between. To give you an idea: the last episodes saw Adam Culp talking about conferences, Kent Beck about application architecture and Konstantin Kudryashov about BDD and TDD.

Listen on iTunes Follow on Twitter

Dev Discussions

In this podcast Shawn McCool talks with other webapplication dev's mainly about programming concepts. Past episodes touched functional programming, event sourcing, ActiveRecord and Datamapper. Shawn recently recorded a talk with Mathias Verraes and Ross Tuck. Let's hope it gets published soon.

Listen on iTunes Follow on Twitter

PHP Roundtable

The roundtable was created by Sammy Kaye Powers. On each episode several developers discuss various topics concerning PHP and it's ecosystem.

Listen on iTunes Follow on Twitter

I'm sure there are many other great podcasts out there. If you know one, please let me (and the other readers of this blog) know in the comments below.

Read more

Forty computer science concepts explained in layman’s terms

http://carlcheo.com/compsci

A handy list for when talking with your project manager. An example:

Asymmetric cryptography

Sharing identical keys works fine among 2 people. What if Alice want to exchange stuff with another guy named Carl, and Alice doesn’t want anybody to see their stuff too? Alice can’t use the same lock and key that she shared with Bob, else Bob can unlock the box easily!

Of course Alice can share a completely new and different lock and key with Carl, but what if Alice wants to exchange stuff with 10 different people? She will need to keep and manage 10 different keys!

So Alice come out with a brilliant solution. Now, she only maintains one key (private key). She distribute the same padlocks (public key) to her friends. Anyone can close the padlocks (encrypt), but only she has the key to open (decrypt) them. Now, anyone can send stuff to Alice using the padlock she distributed, and Alice no longer have to manage different keys for different people.

Read more

Recommended reading: Clean Code

The last few weeks I made the time to read Clean Code by Robert C. "Uncle Bob" Martin. It's loaded with small and big tips and advice on how to improve the readability of your code and why this is important. Recommended reading for programmers of all levels.

A quote:

I am not expecting you to be able to write clean and elegant programs in one pass. If we have learned anything over the last couple of decades, it is that programming is a craft more than it is a science. To write clean code, you must first write dirty code and then clean it.
This should not be a surprise to you. We learned this truth in grade school when our teachers tried (usually in vain) to get us to write rough drafts of our compositions. The process, they told us, was that we should write a rough draft, then a second draft, then several subsequent drafts until we had our final version. Writing clean compositions, they tried to tell us, is a matter of successive refinement.
Most freshman programmers (like most grade-schoolers) don’t follow this advice particularly well. They believe that the primary goal is to get the program working. Once it’s “working,” they move on to the next task, leaving the “working” program in whatever state they finally got it to “work.” Most seasoned programmers know that this is professional suicide.

Read more