After nearly five years at OpticsPlanet, my time there has come to an end. Moving on has made me reflect on all the learning and growing I’ve done in that time. Not only was I fortunate enough to work with a lot of amazing people, but I also joined the larger PHP community during this time. It was great for me and my career. Here are a few of the things that made an impression on me during this time.
The Team is Greater than the Individual
A software developer can accomplish a decent amount on his / her own, but working as a team is a natural force multiplier. If a team of six developers is working effectively, their combined output will be greater than the sum of what each individual could achieve alone. Conversely, a team with serious problems may find that they are producing less than the sum of the individuals. Building and managing teams effectively is the only way for an organization to truly scale.
Everyone has a Valuable Role to Play
Not everyone within a team comes in with the same skills and abilities. A junior dev cannot accomplish the same things in a day that a senior dev can accomplish. A back-end developer cannot do the same things that a front-end designer can do. Specialized roles like Product Owners and QAs probably don’t write code at all. Just because everyone cannot do the same thing does not mean they are any less valuable. Each member of the team contributes in whatever way they can to maximize the team’s accomplishments.
The same holds true for the organization as a whole. A marketing person cannot write software any more than I can plan an effective marketing campaign. We should respect each other’s efforts and recognize that everyone is valuable. The organization would be less effective if any individual were removed from it.
Workflow and Standards Ensure Consistency
The key to building software with consistent quality in a predictable amount of time is to create a process optimized for these things. Determine an appropriate workflow for your team that ensures every issue that is worked on meets the requirements and does not introduce additional bugs or technical debt. Create standards so every developer must meet the same minimum requirements with all the code they write. Identify any problems with the process and make adjustments to address them. If there are too many problems that make it to production, increase efforts in code review and testing. If parts of the process are too time-consuming, look for ways to automate.
The results of the team’s work also depend on outside factors, so these must be considered as well. If the team accepts work with poorly written requirements, it is impossible to determine what should be built and how long it will take to build it. If additional requirements can be added at any time, scope creep kills forward momentum. If the team develops and tests in an environment that does not closely match production, it will be difficult to avoid “production-only bugs”.
There is a Larger Community Out There (and You Should Be Part of It)
Prior to attending php|tek 2011, I vaguely knew there were people out there working on open-source projects. During and after tek, I came to realize that rather than a bunch of disparate project teams, there is a great and thriving community out there. (Or more accurately, there are hundreds of communities that all overlap and for “The PHP Community”, which itself overlaps with other software communities.) Being part of the community is an awesome thing. It provides technical advice, insight into new and upcoming technology, professional mentoring, career networking, and oftentimes friendship. Be active in whatever way fits you best: Twitter, IRC, conferences, local user groups, open source projects, or any combination of these. It will help advance your knowledge and your career, and it helps keep you passionate and engaged as a software developer even when your day job starts to get you down.
Find Your Professional Needs and Wants
As I have progressed from junior to mid-level to senior and then to team lead, I came to recognize the things that I am passionate about and what makes for a good or bad work environment for me. I want to always strive to create the best quality software that I can. Bugs bother me, especially when I discover that the bug was something that was avoidable (with better review or testing before code goes to production). Technical debt is a reality of all software projects, but we should always be making efforts to track it, avoid it (unless there is reason we choose to incur it), and make it a priority to pay it down. These are my own professional needs, and I could not work in an organization with values that conflict with them. I also want things like continuous integration, automatically enforced coding standards, and automated deployment processes, but I am willing to compromise on my wants.
Everyone’s professional needs and wants will vary, but you should identify them and take steps to see that they are being met. If you do not pay attention to them, you may find you are in a job that makes you miserable with no idea what needs to change.
The Next Chapter
I have accepted a position with POLITICO.com and look forward to working with the awesome Samantha Quiñones starting in a few weeks. It’s exciting and terrifying to move on. I am very optimistic about the new adventure, and I am absolutely certain that I will learn and improve in the process.