What it really means to be a “junior” developer.
medium.com
medium.com
Sometimes you don't know what you don't know. Experience often teaches you a lot more than the best design pattern to use, there is a lot of gut feeling involved, especially when it comes to making a decision today about how you might need to modify a feature in the future - you get better at predicting the future with time.
I have been doing this for around a decade now, and while I've done a lot in that time, realizing you have gaps and that you need to do your time to gain experience is very key if for no other reason than not coming across as a know it all in the workplace.
I still have a lot to learn too.
It's not universal. I have no doubt that there are kids with six months of experience who perform better than me after my six years. But, I'd also be willing to bet that's an exception, not the rule.
The technically adventurous are usually right, usually have what most could find ways to agree is technically a better plan, or has elements of it (elements that could stand to improve the technical nature of the product).
But technical superiority rarely has returns. And usually, for most companies, the returns aren't good, not good at all, and those tiny returns are not transferred to the pocketbooks of the workforce that can either hammer out the same old shift as everyone else, or who can go adventuring on genuinely good stuff that genuinely will operate far better. Good stuff, but which will ask much more of the workforce.
The thing with experienced people is, they're done making new experiences. And the thing with businesses is, they don't know how or haven't found grounds to promote exploration of advantageous technical work. This is an industry of get it done, make it work, and finesse and excellence are mired to fuck like every other industry everywhere and not a one of us has any idea how to unobstruct good work, nor do we have a workforce responsive to the call to action even when the possibility is striking them in the face.
There are definitely cases where the green-horns get uppity, absolutely a fact diving in beyond what they can back up in a discussion or technical proving. But classist discontent from those wanting to shake things up, finding a system of work where even those with marginal enthusiasm can participate in a high stakes game without being compelled to shit up the rest of their lives- that's far closer to the root, and it's disgraceful to me that we'd just pick on the enthused widely-read young ones as unexperienced and needing to be curbed, when usually in the work place there's not even a forum for that curbing to happen- the greenhorns are simply denigrated. Often by people who lack exposure to begin to state why. I'd caution that cautioning others that young-guns are dangerous and incompetent further reinforces excuses for this all too apparent denigration.
Thank you my employers all, who have been most kind in cooperating with me in sounding out a middle path between High Tech good ideas and practical and practiced. I think we've done great, and appreciate that we could dialog and discuss the paths without it coming down to the negative experience of the original post or slander of my ranks.
With experience one learns languages, OS and frameworks don't really matter that much.
What really counts is delivering solutions that the customers what to pay for and the consequent business value of investing in a specific piece of technology.
That's pretty much the message of the post.
On the other side of the 'junior' definition is 'senior'. Have been looking at job listings the past few days (for a project I'm working on) and am surprised at how many posts for 'senior software develop' start with 'must have 3+ years of PHP development', and then add jquery or photoshop.
Don't get me wrong - not bashing on PHP (it's a large part of my bread and butter), but I didn't feel comfortable using the label of "senior developer" on myself till about 6-7 years in professional settings. Even then, I was conscious of many things I didn't know (obviously moreso than I was as a junior).
Nan-in, a Japanese master during the Meiji era (1868-1912), received a university professor who came to inquire about Zen.
Nan-in served tea. He poured his visitor's cup full, and then kept on pouring.
The professor watched the overflow until he no longer could restrain himself. "It is overfull. No more will go in!"
"Like this cup," Nan-in said, "you are full of your own opinions and speculations. How can I show you Zen unless you first empty your cup?"
During my interview with the CEO, I was frank with him, I did not went to a CS school, and if you asked me a random CS question I probably would not know, I did not knew how to use properly version control, my skills in the languages they used were lacking, and my OOP skills were also lacking. But we also ended chatting for about 2 hours actually, his early career resembled mine, and we had lots in common, and were likeminded, the CEO during our chat saw where my strenghts were, and hired me.
To my surprise, when I was to do some bureaucratic stuff, my title was NOT Junior, it was "Solutions Architect", that in that company was above Senior...
I wondered for a good while, why? The Juniors around me all knew more than me about basic CS...
I found out, when I could do lots of stuff they could not, they insisted in using whatever they learned at university, and anything that could not be fixed with their existing skills, they would fail to do...
The juniors once lectured me after seeing a "goto" on my C source code (I left it on the screen and went to lunch), yet when I asked them to make a better solution, noone could, all of them create incredibly complicated code, hard to maintain and confusing, and yet they were convinced their solution was better, because their teachers told them to not use goto.
After a while, it became clear, that my title was not for my knowledge, but my extensive experience (I started programming when I was 6 years old, most of the other company employees started during university), and my creativity, the fact I could always handle myself WITHOUT learning CS, meant that sometimes I would see solutions that everyone else would not see... Yet, the CS part I could learn, other employees (that were correctly always above my own title) would happily teach me.
It was back then that I learned how in a proper company with true meritocracy how titles work... Also, a company that actively avoided the problem I forgot the name (ie: the CEO for example told me he would never turn me into a bureaucratic manager, I was too valuable in the tech, to not be near the tech, likewise, there was junior programmers that he would promote to bureaucratic positions, because they were good for them, but lacking in decent coding skills, making them more valuable there)
Indeed "Yet, the CS part I could learn, ..." seems to imply an answer to your final question.
Names, badges ... just smoke and mirrors.
Lots of junior engineers don't know shit, and a lot of senior ones also don't, either. It's pretty meaningless.
I believe the root cause may be a bad culture fit. Either:
A. His ideas really aren't as good as he thinks they are, and he is either not soliciting feedback or receiving it in a productive and understanding way.
or
B. The team does not have a problem solving process which clearly identifies the 'best' solution to a problem for the company.
My main takeaway from the experience was that every time my ego starts to inflate I should take a step back and breathe. I'm not some God coder, I have three years of experience. I realize that this doesn't quite parallel what the author was talking about, but I felt like sharing it because it was a hard lesson for me to learn.
Also, as an aside, my step dad has been developing for 25+ years. He's a really quiet guy, but when he gets talking I realize just how brilliant he is at this stuff. To those already in the field with careers just blossoming, watch out for those who are quietly smart, if he's anything like other developers sometimes they just don't feel the need to prove themselves to you.
I cannot stress how important it is to keep an open mind and to not let your ego get the best of you.
I've been playing with computers longer than some of the guys I've hired have been alive.
They are really smart guys, they are way smarter than I was at their age.
But it's just hard to beat experience and just being around means you've experienced a lot of different things. There's stuff I know where I didn't even realize I knew it until the context of that problem comes up and then all of a sudden, a little flicker goes off in my brain and it seems familiar to something I did x years ago and I can remember why it works like that.
This actually comes up all the time in debugging when something breaks. I've done it enough that the patterns are all familiar and I can pinpoint what broke a lot faster than someone more junior.
This seems to be in stark contrast with the "always keep learning" philosophy I've read on other blogs.
Is focusing on one technology really the best way to be stay valuable in the industry?
life sucks ...
Thats all thats going on. No need to justify it.
That's not a real story, but I'm sure you've heard it before. Or the converse. Or some mix in between. Not really scientific how we base decisions on someone else's experiences.
1. Don't be emotionally attached to your work. Itself obviously horrifically bad advice for everyone: we should be building with passion, in tech the group has fervently picked up and can be excited to roll with. But emotionlessness and removing oneself is a fact of professionalism (to save oneself) and the mired compromise-oriented culture of professional life and business (where historically business plans have always trumped the everloving fuck out of passion and belief).
The linked article? #1 rule of programming, leave emotions at the door? It's not about emotions. It's about pride and hubris, being unable to let go, as the junior developer in the article is, as he is silently unfeelingly antipathically checked without discourse or camraderie from coworkers that simply hit "mute" on him.
2. Design and process is indeed a great caution, something we need to burn cycles on- but the author flat out says junior people don't even think about what they are saying they want to build.
Envisioning and end goal and hacking out some code can be a way of life, can be remotely possible, if your company can parcel up responsibilities in neat little independent units where you don't have to interact with anyone. As soon as you have to work on a project of >1 person, design first immediately becomes mandatory to some very minimal extent. This is a company problem, a danger if you really are leaving everyone running wild and hoping they see the virtues of designing for themselves.
Last, I'd contend the green-horns, with their fancy notions of "what-if," have usually spent more time considering combinations and ways to lay things out than the experienced. If you really do exhibit the well-invested-techie syndrome and you have any self respect, your plan isn't "use redis and node.js and win," there's some kind of data-model, spoken or unspoken and it's up to a company to determine what kind of design proposal process it wants to run for pulling in these ideas and formulating a plan and direction.
The author hits themselves in the forehead by the end: they finally get to process, where they discuss lifecycle. Lifecycle which needs to be the company's lifecycle, which needs to entail design. If a developer is off coding without a plan and there's no process in place where they had to think before hand, yeah, bad news, bad programmer, but how did that happen and why did the inexperienced person not have a standard of work from their workplace they drew from to get in such a bad spot? Did they not see the corporate wiki full of UML diagrams? Did they really forge ahead without filing any tickets for their work?
Honestly some of the best programmers are young ones, because they are humble and they don't purport to know. Experienced ones are the ones coding from the seat of their pants, because they've seen it, they know it, they have assurances and confidence from the past and they're repeating it, day in and day out, and it's not exciting for adventurous for them, it's what they already know. It takes a certain moral rectitude in the junior class to exhibit this, but more than that, it takes a culture that supports discourse and process, it takes a workplace culture that can relish getting into it and understanding what they are doing, and executing first prototypes and then well to plan, and if that idea is hinted at and space is made where a junior programmer can cycle themselves through that and not be looked down upon, they have every chance of being as good today as they will in ten, twenty, thirty, or three hundred years.
I am a Junior Developer.