Being a good engineer is a matter of experience, knowledge, and personal philosophy / attitude. Each of these things can be individually improved upon. Intentionally analyze where you are in your career and in the predispositions of your personality. Understand where you're most lacking and always work towards improving that area.
A developer who is constantly growing is a happy developer that other people want to work with and learn from. A depressed developer stuck in a dead-end learning cycle is a liability to their team and to any project in which they’re involved.
You are not just some code-monkey. You're a problem-solver whose influence significantly impacts (for better or worse) the quality of your organization.
Here are some tips on how to become a better developer. (Special thanks to the developers on FreeNode for contributing to this list of ideas.)
Learn from advanced engineers.
I come from a time pre-internet. My friend Jeremy was the only other person that I knew who was interested in creating software. We were starved for information. We’d scour bulletin-board systems to find source-code that we could read and learn from. Much of it was too advanced for us, but that’s what we had.
Now, the internet is full of guides, documentation is easy to find, and we have screencasts that show us step-by-step how to make new applications. These are great resources and we’re lucky to have them. But, many developers forget about the value of directly learning from the work of others.
Read the code of experienced engineers and aspire to truly understand WHY they made the choices that they have. Work with others to understand. Put away your ego and just study. You’ll be surprised at how quickly you change your tactics.
Fabien Potencier is a PHP heavyweight and he’s a big name in the Symfony scene (consequently the entire PHP scene). The Symfony source is some of the best material to learn from this is available in the world of PHP. Say what you want about Symfony (or better yet, just don’t say anything about it) but there’s a lot that can be learned here.
Taylor Otwell is the engineer behind the upcoming framework Laravel 4, which has been modularized into a suite of components entitled Illuminate. He’s utilizing the power of Composer to put real control into the hands of PHP developers and to improve the quality of the codebase and communities by refusing to lock developers into a specific set of functionality. The Illuminate source is a superb resource.
Take special care to look at unit-tests as well. There’s just as much to be learned here. Unit-tests can function exceptionally as documentation for the capabilities of a project.
Learn technologies that are specifically different from those that you already know.
Do you only know how to develop with PHP? Learn Python or C#.
Only ever use traditional server-side application development techniques? Learn a JS MVC framework like EmberJS. Only use MySQL? Learn ElasticSearch or PostgreSQL.
You don’t need a use case to learn a new technology. Chances are that once you learn them you’ll discover opportunities to use them. More importantly, if you have only used a couple of programming languages, then your mind is simply not thoroughly primed to understand the variety of solutions that you have the power to implement.
If you’re relying on a specific stack (LAMP, for example) then you are literally unable to use the "right tools for the right job." The saying is, "If you only have a hammer, you tend to see every problem as a nail."
An added benefit of learning new technologies is that with every bit of knowledge gained, the next becomes increasingly easy to acquire. This is why experienced developers can pick up a new technology in a day, where a beginner could spend months. Their brains are already primed with all of the concepts necessary in much the same way that learning a 3rd spoken language is often much easier than learning your 2nd.
Join a community by attending user group meetups and IRC.
This is one of the most important aspects of becoming a better developer. You’ll be exposed to new ideas via presentations, etc. But, most importantly you’ll be exposed to intelligent and motivated individuals that fill you with the kind of fuel that propels you through the next couple of weeks of enthusiastic learning. The more regularly you attend, the larger gains you’ll see.
Maintaining a high level of motivation and energy is one of the most important aspects of improving yourself as a professional engineer. If you feel like you don’t have the time to do this sort of thing then YOU are who I’m talking to. With proper management of your brain’s chemicals and natural human tendencies you can be a lot happier and a lot more productive doing what you do.
Take an interest in design patterns and agile development.
While it’s not necessary to buy the Design Patterns bible, it’s necessary to appreciate what design patterns are and what control they give you.
Design patterns teach you both solutions and problems. There’s a good chance that with each new design pattern learned you’ll realize problems that you never considered. You’ll realize how tightly-coupled your code has been and you’ll start to realize that good software design can significantly lower the cost and THE BUSY WORK associated with long-term maintenance of an application.
The best developers are able to quickly adapt their software to changing requirements without having to deal with a bunch of the most mindless and boring types of development.
Becoming a better engineer means being less bored, solving problems faster, changing codebases faster, and being able to do more without being as exposed to the negativities of the crunch.
Don’t create ignorant self-serving opinions.
How often do you hear things like, "I hate Symfony, it’s too bloated.", "I hate ORM because it’s not as fast as my raw SQL implementations.", "I hate Rails for all of the magic." or, "I really just don’t see the point of Coffeescript?"
Frankly, someone designed these technologies for a reason. They all have their advantages and disadvantages. There's a good chance that the decisions that define these projects were based on solving problems that you haven't yet encountered and don't yet know how to plan for. They may also have philosophical differences that lead them towards a different kind of solution than you. This doesn't make their solutions wrong.
The reality is that we have different opinions not only because of the differences in our knowledge and experience but also because of the differences in the problems that we have to solve.
It’s important for engineers to have experience with a wide array of tools and to understand why to use one over another. As stated earlier, if you don’t know more than one software stack then you have no way to use the best tool for the job.
It’s certainly reasonable to dislike a technology because of it’s negatives. But, unless you’ve real-world experience then it’s possible that you just have the opinion because someone that you trusted has it or because you want to give yourself the opportunity to not feel compelled to change. Either way, this is a really bad practice.
Realize what you don’t know and embrace it. Ignorance is a problem to be solved like any other. We're professional problem-solvers, after all.
Rely on your own intelligence.
I have been a provider of IRC / forum support for various technologies for over 3 years now. This is an important point that I feel very strongly about.
You don’t install a technology, play with it for a few minutes, hit a problem, then immediately rely on the help of people on IRC or forum. The people on IRC or the forums that have the knowledge to help you have time as a limited resource. When you’re being helped by someone, they’re not able to help someone else.
Have you ever gone into an active IRC channel for a technology, asked a basic question, and have been simply ignored while other people are around asking more complex questions and getting help? It’s because these people believe that you’re plenty competent enough to solve your own problem without too much trouble and that you shouldn’t be in IRC asking and waiting for a solution. You should be studying the documentation and codebase and creating one.
The hard and fast rule is that you must ask yourself "have I really tried?" and if the answer is "no" then start there.
The real advantage of having access to these experienced individuals is in gaining perspective. If you’re new to development and an experienced developer teaches you her approach to development over the course of a few hours a week that is SIGNIFICANTLY more important than them teaching you something rudimentary like how to use the authentication system or pass variables to a view.
Anyone can learn how to do that by reading the documentation, or diving into the source, or reading the code of other people’s applications.
Documentation is a great resource when it’s available. You can usually learn the API from the API documentation and you can usually get some important perspective on how to think about application development with a particular technology from a ‘getting started’ guide or a more general documentation format.
These resources are here and they’re important. It’s important that you read through the entire documentation for a technology before asking questions in IRC, maybe even multiple times.
If you can’t find what you need then read the API documentation. EmberJS has a good example of API documentation. Here you can see classes and methods and understand what each do.
Source code itself is good documentation. Maybe if you’ve read through the guide-based documentation, api documentation, and other people’s source and question / answers on stackoverflow.com and you’re still having routing problems then you can ask for help from someone else. But, if you’re asking how to make classes load from different folders or something similarly fundamental, you should be heading directly to the source to find your answers.
The source is far more accurate at answering questions than anyone in IRC, on forums, or anywhere else. The source is the part that actually means something.
Don’t short-circuit your intelligence. You’re an engineer. Some aspects of the source etc may be difficult for you to wrap your head around but you can do it and it’s not going to take the rest of your life to understand the code either.
You may say that it just takes too long and that you’re under a deadline. You may well be under the deadline because for much of your career you’ve relied on other people to do your work for you. If you dig in and learn things on your own then you’ll have real knowledge built-up and that knowledge will be yours forever, more or less.
How to Get Help
Now that you've tried to do a good job and have exhausted the other resources it may be time to ask for some help. When doing so it's important to realize that it's rare to find experienced people that are willing to answer your question. Respect the time that these people provide as a free service.
Prepare a list of things that you've tried, all relevant source code, and the exact errors or problems that you're seeing. Read the resources that you've compiled and make sure that they all make sense. It's rude to force someone who is providing free help to do all of the discovery work necessary to be able to sufficiently answer your questions. Give them the best possible set of information from which to work and you will be appreciated and respected by everyone involved. A combination of your work and the work that others expend trying to help you can help people who are otherwise unrelated to you and your problem learn new things.
You should read What Have You Tried?.
Never call anything technical "magic".
We’re engineers. We’re supposed to be the people who denounce witchcraft and explain the unknown with rational answers and utilize thorough analysis to provide pragmatic solutions to complex problems.
We have no business being afraid of the truth. Am I the best programmer? Are you? Are either of us even CLOSE? The answer is no, not by a long-shot. But, we’re professionals. We push forward and improve our philosophy and our toolkit. That’s our job.
Computer Science is too big a field for any of us. As time moves on, specialization becomes increasingly granular and we become increasingly specialized. However, in the end we ALL benefit from a healthy philosophical approach.
We must not be afraid of the unknown. We must embrace it. That is the only way forward and in this profession, if we’re not moving forwards then we’re steadily moving backwards.
Web designers never stop designing – even when we’re just browsing the web.
In my day-to-day surfing I’m always coming across sites that I’d love to redesign, whether they sell products I love, contain challenges I’d like to work with or just call to me for some reason.
That urge is the catalyst for a new series I’m calling One-Hour Makeover. In each One-Hour Makeover, I want to refresh a site and create a new Photoshop mockup in just 60 minutes. The results might be a little rough, but each site only gets one hour.
The site that launched the idea for this series is DoggySnooze.com.
I first saw this brand’s absolutely gorgeous dog beds via fab.com. When I checked out the DoggySnooze site, I noticed that the beautiful product photography was being dwarfed by a design that didn’t provide the sophistication that $150+ dog beds need. All of the great craftsmanship that had gone into the product was lost on the site.
My goal with the DoggySnooze refresh was to produce the same feeling of elegance as the product itself. The idea was to introduce the product, clearly list its unique features, and get people into the shop to discover more.
What I like about the makeover: It shows off the beds and put them at the forefront.
What I could have done better: I would like the call to action higher on the page, and the paw prints in the feature list should be replaced with something more sophisticated.
All in all, I’m pretty happy with this makeover.
Do you know a design that needs a One-Hour Makeover? Let us know!
We're proud to announce the release of our first book. Laravel Starter is a "getting started" guide to Laravel 3.
I've been intending to write a book for some time. Packt Publishing contacted me and it seemed like a good time to get started. Being a Laravel team member and an active member in the Laravel community I have gained quite a bit of experience regarding the kinds of questions that developers new to Laravel have. I used this experience in determining what topics to cover as well as how thouroughly to cover each topic. I'm very happy with the results and am quite surprised at how much information I was able to pack into the book by the end of the project.
The primary chapter guides the reader step by step through creating an user administration system with authentication. It was also important to me to talk over Eloquent relationships, bundles, Laravel's authentication system, filters, and validation.
If you're new to Laravel check it out. I feel like it's a great way to get started getting into the mindset of Laravel developer.
The book is available for purchase in print or as an ebook here.
Big Name has been pretty busy of late and we've updated our work section to reflect just that.
Big Name provided design services for this UK-based accounting software company. AccountsPortal.com was looking for a site design update that was simple, clean, and effective. We handed off our design and we think they did a nice job implementing our suggestions.
Mom Meet Mom helps busy moms discover new friends and schedule play dates.
We're developing the site now and just launched the sign-up page. We're very excited about the technical and interface challenges ahead. We won't be building a dedicated mobile app, so responsive design decisions will be at a premium. Shawn is pushing Laravel to its edge, and he's implementing a lot of great solutions to provide an optimum experience.
Real Change New You was built to provide recovery services for individuals with drug and alcohol addiction and/or HIV-positive lives. With Big Name's development help, case managers now can interact with participants via the site, text messages, forums, and video services.
Having recently converted to Linux, Justin found the ScreenCloud.net services to be very attractive. The ability to have a screenshot uploaded and a link automatically added to the clipboard was huge! So we reached out to offer a hand with the site's design and identity. We're wrapping up some of the last of the app assets and a full launch is imminent.
I wrote this up to answer a question on FreeNode #Laravel and I thought that someone else might find it helpful. A basic overview of how method-chaining works in PHP.
class QueryMaker
{
$table = '';
$field = '';
// this is a static method, it doesn't
// run on an object, it only runs on a class
public static function make()
{
// create an instance of class
// QueryMaker and return it
return new static();
}
// this is not static, it doesn't run on
// a class, only on an object
public function setTable($name)
{
$this->table = $name;
return $this;
}
// this is also not static
public function setField($name)
{
$this->field = $name;
return $this;
}
// again, not static, just renders
// the "query"
public function flush()
{
return "select {$this->field} from {$this->table}";
}
}
Here is the implementation with method chaining
$query = QueryMaker::make()->setTable('users')->setField('name')->flush();
Here is the implementation without method chaining
$object = new QueryMaker();
$object->setTable('users');
$object->setField('name');
$query = $object->flush();
// the output is: select name from users
The methods setTable() and setField() return $this. In that context $this is the QueryMaker object that was created by make().
Let's go step by step:
$query = QueryMaker::make()->setTable('users')->setField('name')->flush();
The static method QueryMaker::make() returns an object instantiation of the QueryMaker class.
$query = $object->setTable('users')->setField('name')->flush();
$object->table is set, setTable() returns the object instance.
$query = $object->setField('name')->flush();
$object->field is set, setField() returns the object instance.
$query = $object->flush();
The flush method is called on the object, returning the string.
Today we are happy to announce bigto.do! bigto.do is a FreshBooks add-on for tracking time on your to-dos. We love FreshBooks, but we wanted to be more efficient when it came to incorporating our to-dos with time tracking. bigto.do is an add-on that will pull in all of the projects from a FreshBooks account and allow users to instantly start tracking time on any to-do item they create.
Currently, we're looking for beta testers to work with us and make this add-on something great for FreshBooks users! If you're interested or know someone that might be excited about this app, please sign up at bigto.do or share this post.
The app will be totally free! Many FreshBooks users are already subscribed to a paid plan and we didn't want to add to that line item.
If you have questions or something you'd like to share, feel free to reply below, tweet @bigtodoapp, or contact us directly at info[at]bigto.do.