I was wondering if this is a safe topic of conversation in a one to
one meeting with my team lead.
This behavior is an acceptable topic, jumping to conclusion as to the cause isn't. I would come at it along the lines of:
Hey boss. I've noticed lately that when I present technical info about the project you always confirm it with Adam or Bob yet when ...
Asking for help when you don't know something isn't weak - no one person can know all the details of each technology they will encounter. And assuming that it's not happening with every aspect of the job, but instead on specific things where you know a colleague has specific knowledge that will help, then it's actually the sensible and efficient thing to do.
I know how you feel; I came from a rural and traditional background as well and went through this several years ago. Here are a few things I wish someone had told me:
These women are not dressing this way to distract you on purpose. Women dress the way they do for a variety of reasons, none of which have anything to do with you.
You will become ...
The short answer: "Because I do not supervise them."
If they don't report to you, you don't control their work or assignments, and shouldn't have to stay late due to whatever is going on, whether too much work or too little skill.
If you are working 60+ hours a week and it still isn't "enough" - then you're at the wrong company. Neither you nor anyone ...
The founder responded that they are overreacting, and that he has an absolute trust in the skills of the new lead, based on his CV and the interview, which is exactly why he assigned to this person the role of a lead developer in the first place.
The head guy has spoken. It's not a government or a political party. You can't throw anyone out or lead an ...
Generally you want to avoid expressing out and out preferences for this sort of thing in a CV but instead make obvious that the company will get the best results by giving you what you want, you're on this lines already but due to the language barrier it doesn't flow quite right. I'd put it something like this:
Social skills: Experienced working in teams ...
Your CEO noticed on Monday that something went wrong. So apparently he or she thought it was fine for themselves not to be on standby.
Fact is: Being on standby is something that people will want compensation for. Especially qualified people who won't have a problem finding a job elsewhere. If I'm on standby that means I can't go to the movies where I have ...
It's the responsibility of employees to ensure that they arrive to work on time. It isn't the company's responsibility to excuse habitual lateness.
If half of your team are regularly late (and they know they are), it's up to them to leave home earlier to counteract the delays, or find an alternative route/method that leads to consistent arrival times.
Am I doing anything wrong?
Yes. You are working 66-hour weeks and taking part in a culture that promotes even longer hours. You are considering going even further into dogmatic presenteeism in which it is a good thing to be in the office even if there is nothing to do.
You will not improve morale by staying late twiddling your thumbs. You will not improve ...
I suggest you focus on the real problem which is that work is not being completed in a timely manner and there is a loss of quality.
If you feel they have too much free time to spend here, then assign them more work and more closely monitor the progress on the work assigned. When the quality problems happen, then send it back to them to fix and give them a ...
He doesn't want us to contribute for Stack Overflow in the leisure time, rather he's
poking us to provide support for mediocre developers who struggle to
complete their task on time.
Yesterday he got very angry and scolded me "Don't
let me to say this once again, it will not be good. Do office works in
office. Take care of your other jobs (Stack ...
With all due respect, I don't believe that the entirety of the problem sits with the staff.
The employees are young and impressionable.
"Most of them are not college graduates they lucked out when they got this job"
Fast forward again, I have had a couple of subordinates file a formal complaint against me stating I am ...
Reasonably frequent code commits.
Document your ideas, your designs and your code. Any gotchas you're aware of.
Document your bug fixes explaining what the problem was and how you've fixed it, and why.
And did I mention documentation?
If you work in an environment where policy is lax (so junior devs can ...
He follows all the company policies for sick days, so from the HR
perspective there is no problem.
Then there's no problem that needs resolving.
Should I approach his sick days in the feedback meeting?
No. If the employee is complying with the company sick leave policy then there isn't anything you need or should do.
While I understand that you may ...
First step is to apologize to the intern.
It's likely both of you are frustrated with how the time has been going. If the intern has had a year of college, it means they are basically a high school student still. Not a professional software developer.
You need to set your expectations more correct. Often (most?) internships aren't really value-add in ...
Here's the secret: Stop working above your role.
You're a developer. The assignment of resources and negotiations outside your department is NOT your role. It is your manager's, and he is executing it.
Your manager is doing things very well, from what I can see. He's preparing you for what's happening soon. Your job is to be ready.
First and foremost,...
As a speaker, I never want to be nitpicked or corrected. I can sometimes handle it when it's important and relevant for this audience. Usually, it isn't. Usually, I've decided to simplify things because I want to get a concept across, so it's not my lack of knowledge, it's a choice.
And yes, I have been in the audience and cringed a little at things I have ...
I myself rely on public transport to get to work. I've taken several steps to mitigate the issues, hopefully they will help.
Talked to my boss about the situation and worked with him to find a solution that worked. This was motivated primarily because last time I moved, I ended up on a less reliable bus line.
I arrive at work 15-20 minutes before my shift ...
If I'm evaluating your performance then Bob and Alice have no bearing on the review. Now truthfully I'm human and I may think of comparisons to each other (and to other people I've worked with over the years) but I need to deliver my evaluation about you in as unbiased a form as I can.
It's the same principle that applies when I reprimand you and ...
You should not share this with people because A) you can't be sure it's her and B) you can't be sure if she wants you to share this with the company.
What you can do, is contact her over this service and tell her people at the company are worried about her. You might even urge her to contact the company herself to tell them they needn't be concerned and/or ...
This is not a technical problem it's a people problem. Treat it as such.
I ain't changin' anything!
You are off to a really bad start and it has nothing to do with the code.
It sounds like your people skills are lacking. You don't start charging into a new job telling the current team how bad they are.
People don't like change. And they really don'...
Based on your comment, you are located in the United States.
If I were you, I would not resign. I would continue doing my job and give the best performance I could (Edit: Exactly for getting unemployment benefits - See first comment), then search and secure a job ASAP. Until they decide to fire me.
At this point, do NOT do what they are asking you to do. ...
Do NOTHING differently. Work as though you are NOT going to be "hit by a bus" tomorrow.
The "hit-by-a-bus" problem is an organizational problem and not something that needs to be explicitly addressed in your own work-objectives.
Your co-workers and management should be thinking about it, but I think it is too much to expect individual contributors to work ...
I've not experienced a problem like this myself, but the fact the asker is trying to stop and finding it difficult does remind me of a surprising but well-established finding in psychology that the harder you try consciously to not to think about something, the more you end up thinking about it and the bigger a deal it becomes. I think this is part of the ...
First of all, objectively present the situation to your team:
Guys, we have been nominated for an innovation award, however only 6 of us, myself included, can attend this event.
Next, tell them when and where the event is taking place, and ask who is interested in attending:
The event is taking place at Restaurant X, on October Y, at Z PM. Who is ...
Should I raise this with my team lead?
No. The most junior member who has only a couple of years experience should not be complaining to team leads about the code quality of the most senior member.
Let the team lead deal with it - there is absolutely no way that you would be telling them something they don't already know. The reasons that they tolerate it ...
This junior developer has a flawed understanding of what a senior developer is supposed to do.
A senior developer is senior, not because his technical knowledge overlaps everything a junior can do (it can, but doesn't have to), but because he can do things that a junior doesn't even understand. The senior developer can (should?) understand broad ...
You now know this piece of software better than anyone.
So, when it comes to the demonstration, concentrate on the parts that work well (or at least work as they should). Any other features that don't currently work that well can be labelled as "in progress" or "prototype". Use these to discuss how these features can be improved upon (or, even better, let ...
The other answers cover a lot, but I will add something slightly different.
Why do your processes allow him access to any production server in an open manner?
You should be setting up your deployment system so it is automated, reproducible and closed - no one should be able to circumvent the deployment system.
Remove all developers access to the ...
Remember that coding does not exist in a vacuum. Even code that's less than ideal can solve real business or humanitarian problems.
Quality is not an all-or-nothing proposition. There are certainly situations where a team is so junior that introducing complexities can kill productivity and morale, and fail to deliver even the basic goals of the entire ...