One engineering mindset that has gotten in my way is the thought that I will never 'catch up on' what other people already know. With 23 of my 26 life years spent codeless, I falsely believed I'd always be working from a deficit and would never break even with the savoir-faire of my developer peers. I never had that same defeatist idea about studying art or foreign language, so wondering "I'm already behind, so why even bother?" was a brand new question I couldn't answer.
What is it about the engineering community that induces such fatalism in beginners? Beginners and experts alike believe that the sky's the limit with web, game, and hardware development, but it's difficult to maintain that hopeful attitude as a new person when stumbling on acronym after acronym or upon a particularly opinionated GitHub issue thread.
One cause at play here is that public street cred metrics for beginners and experts are entirely different. Beginners earn credit by earning badges on Codecademy, sharing links to their first blogs in Rails, or pushing their first apps to GitHub.
As time goes on though, these staggered, sharing-based metrics give way to a different kind of "success." Many beginners, including myself when I started, perceived experienced developers as those having a ton of Twitter followers, a massive contribution history on GitHub, or a collection of Strong Opinions On Programming Libraries.
In reality, those metrics have nothing to do with actual engineering. Having green square after green square on GitHub does not automatically mean someone is a responsible, smart, or admirable developer, nor does their having tweeted X number of times.
I want us to recognize that these metrics of 'mastery' are far too easy to latch onto as signs of programmer superstardom. Success metrics divorced from incremental, visible learning make it impossible for beginners to chart their courses aligned with the engineers they admire.
In other disciplines, signs of mastery are parallel between beginners and experts. New scientists write papers in school; expert scientists publish papers in journals. The concept of 'a paper' remains the same. It is one visible and consistent metric for assessing a scientist's knowledge, from newbie to pro. We do not have such a concrete, approachable metric in programming, and we must be more responsible about how we celebrate expertise.
If the engineering community teaches that "success" is having an intense web presence and being able to condescendingly chuckle about certain programming languages, we aren't demonstrating that studying and patience are the real routes to mastery. Anyone can snidely giggle about XYZ framework, but it takes a truly admirable developer to admit what they don't know or what they're learning.
No matter where you are in your learning, I encourage you all to do anything similar that shows your engineering journey instead of your destination. And beginners, you're not behind! You're already right where you're supposed to be. We all are. ♥
This post was originally published on Tumblr.
Top comments (6)
Spot on! I know because I am one of those "having a ton of Twitter followers, a massive contribution history on GitHub, or a collection of Strong Opinions On Programming Libraries" (or at least I'm getting there) but I can tell you first-hand that I know next to nothing about a huge number of things even in the ecosystem I am working for years now (Java), let alone any other.
I think it is important for everybody's personal development but also for the community as a whole that we acknowledge openly when we don't know something. I tried but nobody wanted to chime in. ;)
I think these posts apply as well: Contempt Culture, Secondary Effects.
Hehe, yeah. I went from not that many Twitter followers to a bunch, and I don't think it was because I became that much more knowledgeable about any part of programming. It was mostly unrelated third variables.
Great post.
Growth mindset is critical: the ability to see that you don't know everything and have something to learn.
Also, what really matters is that you keep solving problems. It's substance, not surface.
The only measurement of a good engineer is by ones peers. If you can do a good job your colleagues will be the ones who are in a position to make a judgment call on if your a good engineer or not.
It's not twitter followers
It's not GitHub stars.
It's not how many open source libraries/packages/etc you have.
It's how much you contribute in your workplace. If you are making life easier for your coworkers then you're a good engineer. There's no other really good mark of skill.
I've seen some new devs who contribute and I've seen old devs who are useless. Age or experience isn't really a factor.
The only time experience comes into play is depth of knowledge, but that doesn't make a good dev. Wanting to help everyone around oneself with creative solutions that solve the problem well, secure, and fast... this is what makes a good dev.
Those who use their giant popular repos, or massive twitter followings, are self serving and perhaps don't actually contribute well in teams. I've met a few of these people. Not to suggest everyone who fits into this category is this type of person, but I've seen it a little too often. They are strong personalities, whom usually have strong opinions, and refuse to think outside their knowledge base.
Junior devs bring ideas to teams. That's why we hire junior devs in teams.
There'll always be a million new things to learn and we can never be experts in all the fields. There is also this tenuous idea of experience, that we will continue to improve over time. If you ever catch-up to my level of experience it means I'm doing something wrong.
There's no end goal with experience, though I know many people treat it that. Job titles tend to encourage this thinking, things like "senior" or "master" or "director" with nothing above those levels.
But there is no top-level with experience. It's not an API or language to master. It's an endless series of hard and soft skills that morph over time.
Our journey should never end.
We're all playing catch-up.
When i worked on my first developer job, i thought that i need to catch up on other developers as quickly as possible to become an efficient part of the team. I was way behind, so i programmed, read articles and tried to learn stuff pretty much every waking minute. Almost burned out in just a couple of month.
I realized that i can't force myself to learn faster. It takes time to understand different concepts. That is something that may seem hard to accept when there's a feeling of being a lot behind on other devs.
I also felt that reading a lot of blogs and articles painted an image about being a software developer that really didn't truly reflect the life at the workplace. Folks may be busy. It's not all about free sharing of thoughts and innovation.