Hot answers tagged

234

There's a couple of things that I've found help a lot with the reception of code reviews: Don't say "you", or variations on it ("your code", etc). You're not ripping apart "his" code or "his" solution. It's our code, or this solution, and we need to do things to it. As soon as someone starts talking about "your" code, a lot of people's natural reaction is ...


108

After two weeks, I can say with confidence that I clearly didn't create value for this company and the other developers that helped me could have done my job instead of spending time with me. You will not create "net positive" value for the company for much longer than that (even when I hire senior developers I assume they aren't net positive for 6 months). ...


102

All code should be peer reviewed (but I've worked in a lot of places where that never happened). How clean is clean? There should be coding standards and guidelines; ask for them. As to how "picky" you should be; that depends on the code being reviewed. Some people like having blank lines pointed out to them, and spacing. Others prefer you spot potential ...


96

A few points in addition to the other answers: Accept that, as a junior, you don't know everything :-)  There may be reasons for the style of code that you are unaware of, such as: Avoiding unnecessary changes to working code (keeping diffs manageable, avoiding introducing unnecessary bugs, &c). Keeping related code so it can be seen together.  (No ...


72

You’re ashamed because you’re growing as a software engineer? The more you learn, the worse your old code looks... just comes with the territory. Keep looking forward, that “horrible” code you’re referring to helped you get to where you are today. You’ve learned, and that’s nothing to be ashamed of. Worrying about those who are judging you is rarely a ...


44

I worked there only 2 weeks You need to give it a lot more than just 2 weeks. Everyone feels a bit overwhelmed when they initially start a programming job. Your first few weeks/months will involve unlearning lots of things you were taught in school/bootcamp and learning how real software work is done. Nobody understands all the code at first glance. ...


32

"Underperform[ing] because [you] didn't like [your] tasks" is the sign of a very poor employee, and, in my mind, you are rather lucky that you didn't get fired given that you repeatedly made changes where your new "features were breaking existing functionalities, or that [your] bug fixes weren't working". It seems like you are now aware of that, and are ...


29

Don't get hung up on junior/senior. No one is a perfect developer, and everyone - regardless of title - has the opportunity to improve. That said, it's important to consider the context. If you're picking out old work that's not really important or relevant at the moment, and then telling them why it's bad quality, that's not going to come off well. On the ...


27

I have been in such a situation a lot of times. And the first thing I usually say is: sorry.... Yes, right... because if he did not get easiest things right, like naming conventions, that means that you (or whoever was responsible for him) did not make a good job in introducing them to him... So apologize for not having given him enough information to do a ...


22

First of all, don't insist on a particular way of taking feedback and learning from it. In particular, not taking notes on paper is not necessarily a sign that the junior does not get anything/enough out of the code review. For most "programming style" code reviews I've never taken paper notes, because I rather focus on talking about the code and thinking ...


18

Welcome to the Jungle. :) Yes. It's normal. You're a junior. It's expected that you will not have a clue, and that's why they're having you do what you're doing. Ask questions. Get the understanding. Ask what you can read on your own time to help you develop an understanding. Be willing to work hard even by spending a few hours outside ...


18

I used to have similar thoughts and problems, frowned upon my colleagues for not respecting best methodologies and thought I was better than most (not saying you think this, but I did when I was junior), but as I eventually become more experienced, I understood I was missing a big part of the picture. I underperformed because I didn't like my tasks Well, ...


17

30 year software development professional here. Perhaps some insight I've gleaned might be of help. Don't sh*t where you sleep. Everyone thinks everyone else's code is crap. This is a pretty natural reaction to reading any code that is difficult to understand. Railing about it, unless you have a good reason to (eg: telling your boss why a feature change is ...


15

Am I freaking out too much or are my concerns justified? You are still new. You need to give it more time. We all go through a similar phase in a new career. I know I did - several times with several careers. Give it more time. Do your best. Keep asking your boss for guidance. my hope is that this situation will relax in the future with some time and ...


15

You can criticise the code, no need to criticise the developers. My guess is they want to do better and a friendly comment from a workmate, worded with care, will be welcomed. It's normal to get in a hurry and be a little sloppy--reminders help correct that. If you've been a developer for 5+ years then the junior/senior demarcation doesn't make a lot of ...


13

When someone messes up badly at the beginner level, it just means they need to grasp the basics. I don't analyse their mistakes and try and teach that way. I already solved those, and there was a probably a bit of cursing going on so old news. I just run through the basics in detail. By that I mean the conventions, procedures, etc. Importantly I teach him ...


11

There is a bit of a false dichotomy in your final question. First of all, training courses are not considered professional (or commercial) experience, because it does not meet the definition of professional experience. There may be courses where you may have a placement within a professional environment, working on professional project, and that may be ...


10

The thing is that I really didn't like it, I was also working on micro-features and I felt that I had coding-monkey tasks, so I made the horrible mistake of not giving importance to my tasks, also because I though that they weren't so important for the company This is indeed a horrible mistake. For your company these tasks might indeed be not that important,...


10

First of all, what you are passing through seems to be some sort of imposter syndrome, so thanks a lot for coming forward. As a junior developer you are following requirements and making sure they are met (and maybe raise some concerns on the way things ought to be implemented?). With that, you don't need to feel ashamed/sad as you are developing what was ...


9

Like everybody is saying, two weeks is nothing. You will take far longer than that to get up to speed. And your manager and colleagues expect this. I would like to grab one sentence to comment on: My problem is that I have to write tests for methods that I don't understand most of the time, I don't always understand which parameters they have to take, ...


9

Major issues in the logic, lack of knowledge for how to trace back an issue to the root cause, and very obscure naming conventions (this was very problematic due to the nature of the project). I would start with the easiest first. "Naming conventions" Your company probably has a guide. The book Code Complete 2 can be a pretty good guide too. It ...


9

The situation isn't bad, it is good. Once you get your head around this fact, the talk will be much easier. The project was finished on time. You have the time and expertise to further improve the project that already does what it is supposed to do. It is perfectly natural in software engineering to have architectures that are not optimal and to improve ...


8

We all look at our old code and cringe a little. This is completely normal, but what many of us do not experience is the desire to quit over it. Don't quit over something normal, instead focus on the fact that this code which you find undesirable, was seen by the company as good enough to merit a promotion. Learn to laugh at your own code, how noob it was ...


7

Is it a sign of me being basically 'too dumb' if I still need to ask questions after almost 2 years? Not at all. But it sounds like you're asking the wrong questions. I asked an experienced coworker if he could give me a quick introduction. That's beyond vague, and sounds like you haven't even tried to figure it out. If you asked me to give you a "...


7

Programming isn't like being a gas fitter or pilot, where you need to be certified on a specific task, because you're rarely asked to do the same thing multiple times. What is important is the ability to pick up a new tool, skim the manual (if there is one), dive in and have a go, troubleshoot and fix your mistakes. You can't get certificates in that, but ...


6

It's good to have a certain course completed from a widely-known certification authority (online of offline) and have the certificate, but most of the time, that counts towards your proficiency level and theoretical knowledge. Majority of the cases, they are not considered as professional experience. If you have pet-projects which you can showcase, that ...


6

1 - Is it normal? Yes. Sitting there, staring confused at alien code and asking yourself what you are doing is normal at all levels, even after decades of experience. What changes is how you handle it. 2 - What can I do better? Keep at it. Two weeks is really nothing to worry about. I was once the teamlead / lead dev for an application like yours, and ...


6

Some observations: A scrum master is not a manager, except in top-down driven fake scrum. A scrum master is more of a coach to help the various participants stay on track. If this company gets more funding, you will spend a lot of time planning, recruiting, hiring, and putting together a team. That's what early hires do at startups, regardless of job title....


Only top voted, non community-wiki answers of a minimum length are eligible