The 2016 is the 10th year I am working full time in the computer science field. Before that I had graduate school, a startup, an undergraduate degree, high school - always programming. My first programming experience was when I was approximately 12 - a couple of people at my dad's work showed me how to use an operating system (MS-DOS), and how to program using Turbo Pascal. I have worked at tiny startups and at large companies; here is my advice to any engineer who is considered to be a "senior" at any company. You should be doing the next three things.
Actively fight complexity
My main responsibility is fighting the code and system complexity; fighting it every day, in every aspect of the business solution we program. Often I fight other engineers who are willing to live with it; or even fight engineers who are keep adding to the complexity without taking a step back to reevaluate the results.
It goes beyond the simple technical debt - in fact paying the technical debt often increases the complexity, because now you must cover more edge cases. The complexity usually creeps in unnoticed and unintentionally: just another tool in the pipeline, another small prerequisite library, a few more steps to run through before one can test the website, etc.
Left unchecked, the simple prototype or new application slowly grows to be a monster. I have seen this over and over: a quick and productive work week starts grinding to a "dead or alive" sprint. Each feature or a bug fix is hard to code, and it becomes even harder to verify that nothing else has been broken in the process.
The simplest way to fight complexity among multiple moving parts is to physically and logically separate code into smaller chunks. I hate huge projects, they suck the life out of everyone working on them, and worst of all: they are never finished. Splitting the project's code base, moving the parts into their own "worlds" with smaller surface area, fewer requirements, faster build and test times - that is the fastest way to restore the team's sprint velocity (number of new features shipped and bugs closed).
A fresh graduate or someone with less experience cannot be a good complexity fighter. Knowledge of fewer languages, less experience with diverse stacks - one cannot solve or even estimate the solution without spending a few years fighting each particular environment.
Someone more senior can estimate time savings and write a missing tool, or a testing library. Or replace long bootstrapping process for each new hire with a single command
Remember:
Either you take the complexity head on, or it overwhelms your team
It is very easy to simply do one's job. Code a little, test a little, maybe demo the completed feature once in a while. It is much harder to actively share knowledge among the team members. As time passes, we all become insulated in a tiny bubble; seeing only a part of the code and tools. Members of the same team might have overlapping bubles, but we are slowlly drifting away.
As a senior developer I must share what I learn. Only by showing things I have done, or talking about the things I would like to do, I can explain new code and ideas to others. Mostly I write the blog posts for myself, otherwise I forget. This year I also wrote a couple of tutorials that start without any assumptions and can be read and followed by everyone.
At a company, it is often hard to justify the time investment; but I always argue that this is the best way to have engineers grow professionally and stay engaged. Making the knowledge sharing officially scheduled on the company calendar, and making everyone take turns ensures that learning and sharing becomes a normal and even routine part of the work; and that everyone participates.
I also recommend focusing on the outide technology and examples the primary topics, instead of just demoing written code and features from the current sprint. It will keep the engineers engaged and NOT defensive or cautious in selecting what to share. If I have to show only what I have finished for this sprint, I am limited to 1% of what is available to show in the current JavaScript and Python community, and that is no fun.
The knowledge sharing role has several important corollaries.
- You must teach others what you do, so they can do your job. If you want to protect your position, you must do so by making new things, not being the only one who knows how to do X.
- You must foresee questions from developers at multiple levels of experience. A lot more questions might come from people who are beginners than experts, which makes sharing knowledge and training more difficult.
The key take away:
To really understand something, you need to teach it to others
Participate in the community
We use many many tools and libraries developed by others. We also worked at companies before our current job, and we WILL work at many others before our careers are over. Geographically we are in a technology hub (Boston). A healthy engagement with the community around us: based on tools, experience and geography; is a must for any serious company that exists for longer than a month.
In practical terms, I see the senior engineers contributing to the community, while the company benefits only indirectly. I attend local meetups, write blog posts (like this one), speak at conferences, and open source lots and lots of code.
In return I get the name recognition, and my company gets the mention too. Both lead to a strong recruitment tool - given a choice, would you rather work in a secret gray box, or with people who you have seen speak; whose code you can see and use yourself? It is like we do a reverse interview - the candidate can see what we have written; and hopefully be more eager to work with us.
I encourage every engineer to start the engagement by speaking at a local meetup; it is really not that difficult to pick and prepare a topic that will be interesting and relevant to many listeners. Speaking at a local meetup will help the speaker refine the ideas, polish the delivery and work on the carreer path, rather than a job.
The key take away:
Strong engagement with the community brings indirect benefits to the company and direct benefits to the participants.
Conclusion
I listed 3 things I try to do as a senior engineer on the team: making things simpler, sharing knowledge and engaging the with community. If these 3 items have a common theme, then it would be: as a senior engineer you must
Take the freaking responsibility for everything that happens at your job.
You know the programming language (or many), the tools and how to use them. You must learn how to help other engineers reach higher level, how to encourage them and how to encourage everyone to reach new goals. There should not be any complains from you about tools or the factors outside your control - you must take the reigns at some point in your career.