The consistent Petr (part 2)

In our project we have this Sentry integration that would let us know when something goes sideways (I am sure most devs know what I am talking about).

About a moth ago (all of devs and dev-ops) have missed one notification (we were all in a meeting an ignored the email) and live site was unusable.

Ever since I made a rule (for myself) to put the errors in a common Slack channel for all the devs to see. All good, no one was bugged.

A few days ago, Petr makes this announcement:

“Note – it seems that current errors from production are maybe false-positive and they are not affecting user. Sentry integration will be updated shortly.
Second note – even these errors may be false, we will still take a look into them.”

Today I see tow dozen errors in my emailĀ  and I notify the devs, that maybe something went wrong, as there are too many different ones. If they are nothing than only 5 mins of our lives were lost.

To my notification I get this from Petr:

Yes, the FE errors on production were mentioned on stand-up and also in #frontend channel. They can be false positive, due to complications with Sentry integration.

There was no mention of said errors in any of the stand-ups this week or past week.

The consistent Petr (part 2)

The consistent Petr (part 1)

This morning, when I got into the office, I was surprised by my tester who said that none of the bugs I’ve put in for testing are fixed. Imagine my amazement when I checked the bug-branch I was working on and the testing-branch and they had very different code! So I go to Petr and:

Me: hey Petr, did you get any conflicts when merging the bug-branch into the testing-branch
Petr: Yes. But I fixed them. I kept the testing-branch code
Me: You should have kept the bug-branch code as it was the newest one (and I added it to fix some bugs reported on the testing-branch)
Petr: Yes, yes. That is the one I used.

Half of the day has passed since and we still have different versions of code even though the bug-branch was merged into the testing-branch…Petr is on it (fixing).

The consistent Petr (part 1)

What is a senior developer?

There was a very interesting discussion in the office today about what a senior developer is (we were talking about JavaScript developers, but I guess it could be applied to any programming language).

I was saying that there is no possible way that a developer can be senior after only 2 years of experience. There is simply not enough time to meet the unexpected. And that is what, in my opinion, makes a senior: the unexpected. The ability to not be surprised and blocked. That is when a developer becomes senior.

There were of course voices that said that 2 years is more than enough. And it only depends on how passionate you are (how can passion be a factor in establishing seniority?). Then there was a slip from someone who said: if you convince your current employer to make you a senior, than you can put it in your CV and the next job recruiter would have to take you into account for a senior role. That made me think: hm.. sneaky one. So you you put it in your CV just for to market yourself? So the seniority became just a keyword? Who is to blame for this? Can we fix it?

About 3 years ago someone estimated that the number of programmers doubles every 5 years. I suppose then, there is this need of making oneself appear “seniorer” than the rest. But is it fair? and I mean it. There are senior developers with less than 2 years of experience and less than 25 years of life who participate in technical reviews during interviews (and I mean it because I have seen it) and they evaluate people that have more years of experience then they have of life, only to conclude that the respective developer is not good enough. I guess I am a bit afraid that I will one day be evaluated by one of these. And maybe I am more afraid of my reaction to it. I am afraid that I will try to impress this kid into hiring me. Is this ok? Is there something wrong with me? Are there any others like me?

 

What is a senior developer?