git

I'm a person willing to constantly improve her skills and learn new things.

Recently I've read a nice article on being a senior engineer .

I've also been talking about hiring new engineers, about interviewing process and desired level of skill.

Differences between senior and junior

What is the real distinction between senior and junior engineer? Is there a middle position between?

Is this an amount of written lines of code, of succeeded or failed projects? The technical skills you acquire in the meantime? Willingness to take responsibility of what you do? Or maybe just years in the industry?

Here is an answer from stackoverflow.

For me a junior was a person without much or any production experience, but having technical skills. Not an expert, but active learner.

Of course there are different juniors out there. Some are awesome, some are merely mediocre. Same with companies which hire those "new" people. Some are better than others.

Thougths on being a junior

Looking for a good definition of junior software engineer I stumbled upon some interesting articles about having an internships:

Here is a little rant on microsoft, and blogpost about totally different experiences in mozilla.

From junior perspective is a post about "what it really means to be a junior developer".

Gaining experience at work

I think that good internship or first job can make a huge impact on future work of an junior programmer. The people you meet, the way you work.

  • do you use version control
  • CI for testing your code (oh yes, testing)
  • do you make peer reviews
  • are you agile
  • working in a team
  • handling criticism and feedback

It sets a baseline. You can bring up a good programmer. I think that we should empathise that giving people possibility to grow is really important. Of course everyone wants results, but... becoming an expert takes time and diversity in age, sex, experiences and thoughts can be really beneficial.

I was lucky that I had my internship at TouK, which taught me what it means to be agile, how to do test driven, develop for the web, use source control and linux at work.

It made a huge impact on my later work.

Working on side projects

Working on side projects is great to try out new technologies, to actually create something and gain experience.

I remember my first programming interview, before the talk I was asked about code samples. I haven't even known that github exists then.

I haven't used version control before and had a trouble collecting some reasonable samples of my work. I actually wrote something then, because what I had wasn't much but I had two small projects.

It also teaches managing work-life-balance.

I love doing side projects but they are really time consuming. I try to code often and rather regularly but I have bursts of activity, what is visible on my github account and it sometimes a bit destructive. I sleep less, forget about meals, exercise, etc.

Learning every day

Whenever I do something, I try to learn something new. It accumulates. You should never be stuck doing things inefficiently.

Typing slow? Learn fast typing.

Inefficient in your IDE? Switch to vim, or other way round.

Feeling uncomfortable about something? Become an expert (or just learn some and use it).

Dealing with failures and criticism

Everyone makes mistakes. It can be really painful.

You really didn't want to introduce this bug to production, but you did.

Everyone now thinks that you're stupid and careless, right? No. Everyone makes mistakes. Maybe you haven't seen it yet, because... you haven't seen much yet ;).

Or you are being driven crazy with some strange bug? Well, it's part of developer's life.

Don't take criticism emotionally. Crying, feeling bad about yourself, or being angry with this stupid bastard isn't the optimal solution.

Not being an expert is okay when you're learning.

Thoughts on being a senior engineer

Returning to article mentioned in the beginning of this blogpost, on being a senior engineer

from kitckensoap, what really defines a behaviour of senior engineer? .

  • seek out constructive criticism of their designs
  • understand the non-technical areas of how they are perceived
  • do not shy away from making estimates, and are always trying to get better at it.
  • have an innate sense of anticipation, even if they don’t know they do.
  • understand that not all of their projects are filled with rockstar-on-stage work.
  • lift the skills and expertise of those around them.
  • make their trade-offs explicit when making judgements and decisions.
  • don’t practice CYAE (“Cover Your Ass Engineering”) (An example of CYAE is “It’s not my fault. They broke it, they used it wrong. I built it to spec, I can’t be held responsible for their mistakes or improper specification.")
  • are empathetic.
  • They don’t make empty complaints.
  • are aware of cognitive biases

What I see in the list above is just a bunch of cultural/personal features of an empathetic, nice and educated person.

Can't you be a badass and good senior engineer in the same time? Can't you be just out of school and apply this attitude? Lot's of those I would connect to emotional maturity.

Becoming a senior engineer faster

I'm one of those impatient people. I want things to happen just now. But is there a need to hurry?

So maybe just 10 years of teaching yourself programming while working on emotional maturity and creating projects?

Conclusions

What do you think? What would you recommend to young programmers, people wanting to become software engineers/hackers?

How do you handle being an inferior programmer (yeah, juniors work is often treated as worse) even if you're trying your best? How do you learn all those things you don't know?

Or if you're a senior, are you a good senior engineer? What do you do, what is different from work of typical junior?

I would really like to have more levels in between. Leveling up would be easier and more gradual. Transition from intermediate junior engineer to upper junior engineer doesn't look as daunting after all.