In discussions about data management, will I be discredited by speaking up about my ideas?These are the feelings that I had to manage in my earliest days on this new team.
My greatest fear was that one or more team members would be a real Linus Torvalds kind of character: vastly superior programming skills, and absolutely no time for my clown shoes.
But I was incredibly fortunate, as my team was supportive, patient and generous with their knowledge.
They actually wanted me to succeed.
I learned some really important lessons working for them:Have EmpathyFirst, there was the recognition that the work we do is difficult.
It’s complicated.
It’s screwed up into a ball of yarn by the fluid requirements of product managers and marketers.
The best way to deal with the chaos is to have empathy: suffer the errors in the code and realize that nobody on the team is perfect.
In a way, it means that we can use humor to transmute Imposter Syndrome into a healthy respect for the work that we do.
Simplicity WinsSecondly, I learned that I don’t need to impress my teammates with brilliant code.
Simplicity wins.
I’m writing code not just for myself, and not just for my future self, but for my future team and the developers who haven’t even been hired yet.
I worked on code with headers containing the names of coders who’d left the company a year ago or longer.
And now that I’ve been gone for over a year, it puts a smile on my face to think that a file like AssociatedValues.
swift, with the header “Created by Aaron Vegh on 2016–02–19,” may still be used today.
I want to write my code to be clean and simple so that others can keep it and work with it.
Have Professional StandardsI’ve also learned that while technical ability is obviously important when hiring a developer (and, it turns out, not to be taken for granted!), I’ve come to believe that having professional standards is just as important.
When I worked alone, I could fudge certain details in the code since only a few users might run into a rough edge.
On a team, with an app that will be used by millions of people, a feature has to be done right.
The code has to be clean.
A bug must be fixed conclusively.
Hacks, kludges, and bad code smells are unacceptable.
Attitude MattersAnd finally, I learned that attitude matters.
I’m definitely no Tony Stark, but I’ve learned the importance of projecting confidence, and more importantly, eagerness, to take on the jobs that other developers don’t want to do.
Instrumenting a score of features for analytics?.I’ll take that.
Implementing a complicated, multi-level set of scroll views inside a nested custom tab control?.Gimme.
Hunting down an elusive bug that’s the top crasher and nobody knows why?.Let’s get in the trenches.
Over time, the process of respecting the work, writing clean code, insisting on professional standards, and having the right attitude helped me climb over that bulwark of Imposter Syndrome.
It makes sense: the more success I have, the harder it is convince myself that I can’t do the job.
That’s not to say the feeling is gone: there are still times where I vacillate between feeling utterly masterful and completely inadequate, even on the same day.
The work is a process, and by consistently demonstrating an ability to make the team stronger, it turns out that I can deliver my best work in a team dynamic.
Our app is better than anything I could have built myself.
And it affects the lives of dramatically more people.
Iron Man alone is pretty good at knocking off one bad guy, but it takes the Avengers to fend off the Chitauri.
.