DEV Community

Cover image for What were your knowledge gaps when you started your career?
mikel brierly
mikel brierly

Posted on

What were your knowledge gaps when you started your career?

Alt Text

When developers sweep mistakes under the rug and cover up gaps in understanding with jargon and obfuscation, we reinforce the wall of imposter syndrome. Let's be inclusive and share what this journey is really like, warts and all.


Stuff I think is reasonable to not understand:
📌 higher-order functions, threads, closure, execution context, recursion, OOP vs Functional programming, a million acronyms everyone seemed to be throwing around

Stuff I probably should have known:
📌 Using an IDE, the difference between front-end and back-end, Node debugging and Chrome dev tools basics, using debugger instead of console.log, what is pure JS syntax and what is framework,

Stuff I'm not sure is "beginner" or not:
📌 this and prototype, merge conflict resolution, [reading [documentation]], the call stack, web API


I'm really curious what your thoughts are on this, and what your own lists will look like!

MTFBY

Top comments (17)

Collapse
 
190245 profile image
Dave

When I started, there was more gap than substance. Now, I find myself hiring. So my list for junior developers:

  • Be passionate about learning.
  • Don't be afraid of the unknown.

That's it. I mean, sure, I'm not a university lecturer, if you don't know how to at least build & run code in the IDE that you're choosing (since we don't tell everyone to use the same)... I won't be hiring you.

Everything else, is nice fluff.

Money where my mouth is, I've just hired a guy that's still finishing university. No checks with his tutors, no conditions on his contract, just a 1 hour-ish Skype call and a regular job offer with junior salary.

Re your list of "not sures":

  • this & prototype - who cares if a junior doesn't know it, or has a personal preference on when to include this for example.
  • merge conflict resolution - nope, that's what GitFlow & Senior Developers are for.
  • the call stack & web API... they seem mostly framework dependent to me, and while interviewing, I might change my mind about the primary frameworks etc... little unfair for me to think a candidate has a hope in hell of understanding them in any detail.
Collapse
 
mikel_brierly profile image
mikel brierly

Dave, thank you! This is exactly the kind of conversation I was hoping to spark. I really like your two item list of requirements. I suppose my list is a bit overly specific, and what's most important is more soft skill related than knowledge or memorization.

Collapse
 
190245 profile image
Dave • Edited

No worries - if it's helpful for you or anyone else reading this.... this is my list of requirements for Seniors:

  • Know your onions. If you make claims on your CV, I will be assessing those for truth/little white lies etc.
  • Have a back bone. Don't be afraid of interrupting people (even in the interview) when it's justified. Be opinionated. If you say it, follow through on it. Balance this with a healthy dose or respect, and therein, lies the art.
  • Be passionate about teaching. I don't want egotistical rockstars, I want people that will drag up the team average by levelling the playing field.

For everything that isn't a soft skill - there are many search engines at our finger tips. Hell, search engines work for soft skills learning too.

Oh, and with regards to seniority level - we have one job title - "Developer." Best way to level the playing field is by not starting people on different labels.

Collapse
 
juniordevforlife profile image
Jason F

Debugging large applications was a mind blowing experience. I got my start working at a small company whose flagship product was (at the time) running on .Net Framework 3.??( it was 3 dot something, don't remember the minor version). The interview to get the position was basically a few different tests and interviews to make sure I understood XML, SCSS, JavaScript (ES5), and C#. Once I got started at this position, I was completely blown away by the size of the application. Debugging this thing was intimidating to say the least. I think it would have helped me out to have been exposed to some large applications before starting.

Collapse
 
mikel_brierly profile image
mikel brierly

Yeah dude I hear you there! A file more than 100 lines scared the crap out of me at the beginning. What do you think could be a practical way for newbies to get exposed to large applications at the get-go? I know open source is always a good plan, but it is also massively intimidating to try and break into

Collapse
 
juniordevforlife profile image
Jason F

Mikel, you're totally right about an open source project being intimidating! I do believe there are small open source projects out there geared towards beginners, but they may be hard to find. A year or so ago, I ran a small open source project that was a small Brewery Finder site built with React and Bootstrap. The entire goal of the project was for beginners to be able to get their feet wet with going through the steps of working on a project (clone, debug, make a PR, etc). I'm not aware of a place where projects like these are compiled and shared, but would be cool if that did exist.

Thread Thread
 
mikel_brierly profile image
mikel brierly

That's awesome!! Thanks for sharing!

Collapse
 
cbear1988uk profile image
Collin Bull

One thing I learned on the job/internship that my bootcamp did not accurately teach us was to navigate ceremonies.

My first(and so far only) gig was in an agile team that had sprints that were two weeks long as well as fortnightly releases. With those two week sprints;

  • we had a backlog-grooming session where we had to layout our following sprint's workload with a breakdown of tasks, how long to complete, etc..
  • we had a sprint-planning session where we were meant to fill our task-board with enough work for those two weeks and accurately estimate how much time we needed (which I always either under or over shot)
  • two daily stand-ups (one for our immediate team and one for the wider business)
  • A Show & Tell at the end of each sprint where we were to demonstrate to the business what we have worked on
  • A Sprint review where we evaluated our tasks and performance which usually ended up being a broken record of "here's all the wrong things the interns are doing"

They threw us in the deep end and expected the interns to just dive into Agile methodologies and ceremonies like we knew what we were doing.

I'm not sure if this knowledge was more our burden of responsibility, our bootcamp's, or that the company had higher expectations when they hired us. But either way it felt like being in front of a class naked nearly everyday.

Collapse
 
mikel_brierly profile image
mikel brierly • Edited

Oh man that's a great point I didn't even think about!! Agile is almost religious for some people, and it's a badge of experience to know as many obscure acronyms as possible. Especially if you're an agile SCRUM master pivoting to hit OKR's with synergistic energies. (Let's talk about the burndown chart offline).

But for realz thanks for sharing Collin, these are the things that are easy to forget when you've been doing it for a while. Empathy for beginners evaporates when you don't remember how embarassed or lost you felt at the beginning. It's good to remember

Collapse
 
juliathepm profile image
Julia Flash

Networking contains the umbrella of things I had to learn when I began.

Collapse
 
mikel_brierly profile image
mikel brierly • Edited

Thanks for the reply Julia! So the people you met via networking helped you understand what you might need to learn? And what were some of those skills?

Collapse
 
juliathepm profile image
Julia Flash • Edited

Oh! So networking as a discipline, OSI layers, how DNS works, AV setup for workshops, intricacies of HTTP methods, various cURL commands, data loss and reasons for it. I knew some from hacking and the protocols from that but was a script-kiddie when I began that. I did not know programming very well so I touched on it by programs but still years ago I did not know what all of it truly meant in the workings of it. I started understanding it when I was placed in situations which forced me to learn it. You know what I mean? So not social networking but actual network-networking. :)

Thread Thread
 
mikel_brierly profile image
mikel brierly • Edited

🤦 Ahhh that kind of networking! Thank you for elaborating!!

Collapse
 
ryan1 profile image
ryan

My big gap was understanding that Software Engineering is a team sport.

Collapse
 
lexingdailylife profile image
Martin Cartledge

I love this - I wanna tattoo it on my face

Collapse
 
annietaylorchen profile image
Annie Taylor Chen

I think it's the TCP/IP, CORS, CI/CD, setting up the correct boilerplate with right tools, deployment on the VPS.... Should I know all this to be considered as hirable?!

Collapse
 
mikel_brierly profile image
mikel brierly

I think if you're looking for a job as a web dev or anything outside of devops or networking, you should be fine. CORS seems to come up a lot for me personally, but I can't imagine a reasonable company making any of the things you mentioned a requirement for someone just entering the field.