New answers tagged

1

These kind of requirements can arise out of several possible sources. They are filling the position based on a subsidy or similar funding arrangement. Globally this kind of thing comes up in different forms, ranging from direct "Government paying companies to hire newbies so said newbies can gain useful experience faster", to tax breaks or other schemes. ...


1

I think this is from hiring staff copy and pasting existing job postings and then editing them. Even if it doesn't mention internship anywhere in the posting it probably is for an internship type position they just re-used from a normal full time salaried position posting.


0

In top of the answers I think the problem is about confidence. your developer is confident of using X and afraid of using any other language he is not so good at. probably a training in the capabilities of your Y language may give him some confidence in using Y


-1

Consider the possibility that your developer (the one who really likes X) is on the autistic spectrum, or at least has autistic traits. The obsessive focus on one thing, talking about it all the time, may indicate that this person has some sort of condition, which makes it difficult for him to approach the matter objectively. The reason why I'm saying this ...


4

No, language X itself is not really the problem. What you've described here are the symptoms of a much deeper problem that will affect all the other systems your team produces as well: the team isn't really working as a team but instead as a bunch of disconnected individuals. Your instinct that you "want [your] team to be autonomous and happy, building them ...


7

I think you're approaching the problem from the wrong perspective. You are turning it in our pet language vs. his pet language problem. Languages are only tools, quite universal one, so their choice is a side issue. The real problem is that you have a total chaos in team. It looks like everyone can do what he want, choosing any tool, even those he's ...


1

I'm now happily employed and wondering if I should clean these out, or leave them so my 'contribution history' shows the time I've spent learning? I don't see any reason why you should delete them. They contain code and code snippets that you've made and that someday may prove useful to reference or reuse. Also, given you are already hired, I don't see how ...


7

It depends on what the purpose of your GitHub account is, but since you posted here, I'm assuming your intention is use the GitHub account as a showcase for your skills. In that case, you would do well to whittle it down to the projects you are actually proud of and want to show off. No potential employer is going to sift through 88 different repos to find ...


0

I think you should remove your older repositories (could be done by making them private), simply to help people find the interesting projects easier. There is a high probability that someone is randomly looking at projects and misjudging you just by chance. So just clone all old repositories, zip everything and store it somewhere.


10

Is X itself the problem? No. X is not the problem... for every value of X This is a management problem. As a new manager, you landed a tough one. You problem is that you have a very enthusiastic programmer who you would like to redirect into a more productive employee. You suspect that if you tell him he can't use X you will have to replace him ...


1

You should make it obvious for the higher-ups and the team that X in its current state is a problem, because apparently there is currently no understanding that this is the case. Tell everyone that the team needs at least two X experts, in case one of them calls in sick. Ask for a training in X for the whole team. Every time the project breaks because of an ...


8

As others have said, this situation should not be allowed to continue. It does indeed sound like the fundamental answer is going to be of the form "No, sorry, you can't use X." And you are well within your rights to say that. Your worst case scenario is this dev gets upset and quits. That would be sad, but is his perogative and your answer should probably ...


2

Building on other answers, I agree that languages/technologies to be used in the project should be positively selected by the team before being used (excepting possibly a trial or test case for feasibility, with no promise or critical-path to be used in the project itself). I worry that that wasn't done, and trying to bring the topic up for discussion with ...


39

Absolutely not! Entire companies have died because they picked the wrong language in which to write their codebase. If the language dies, becomes unpopular, or leads to intractable scalability issues, the code dies too. Can you afford to rewrite it? When you need to completely rewrite a piece of software in a different language, you will be a sitting ...


44

Hard no. Pet languages, or even excessive numbers of languages, getting introduced into a project make it completely unmaintainable in the long term. When the developer leaves, you'll end up with the code in their pet language in whatever status they left it in, and a pile of workarounds in the other components to get things done without having to change ...


-1

Sounds like you are working in a toxic environment. Asking questions is not a crime. At most places it is welcome. Just make sure your questions are organized and not continual. Produce a quality product. Don’t let these people distract you. However you might want to start looking for another job.


1

often task descriptions are vague or straight up incorrect, and I am expected to remember verbal discussions that directly contradict the story descriptions. I am bad at remembering verbal things, which is why I rely on notes and written story descriptions a lot, but they are often unreliable as changes in requirements are not documented. I feel ...


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 "...


71

I'd be very, very concerned about this. If he gets hit by a bus tomorrow, or decides to leave tomorrow, then you currently have: A massive cost, both time and money wise, of finding an expert in X to replace him; A team that doesn't understand any of the code he's written; A team that can't reliably even deploy any of the code he's written; Code that is ...


1

I think you need to have a discussion with the team on this language. Let the developer to present the language first, hear the advantages the language can give as well as what disadvantages language has. Bring up your concerns about stability, compatibility, etc. Take a look on the track record of who developed the language (for example Microsoft is known ...


15

This is one of the few things were I think a manager should put his foot down and not give in. What the developer is doing will hurt the company in the long run. And it doesn't matter what X is -- all that matters is that your company does not have a lot of expertise in X, and it will be hard to attract expertise in X. Your developer is wrong that X is the ...


93

How can I handle the risk to the project presented by X? To address this, I am going to use your own words: it's evolving fast / unstable - on going to document some older code, he found some base functionality had been removed, wouldn't compile in newer versions, so took a couple of days to re-implement it AND the other devs are clearly ...


136

I suggest you put the question up for discussion to the team. Present your concerns at the next team meeting and ask what they think about them. Since they sound like valid concerns I would imagine you'll get support from the other developers. Make sure the discussion stays professional and keep an opened mind. Focus on how using X affects the rest of the ...


1

Wasted your time? Everyone of us is always learning something - consciously or unconsciously. By "wasted" I suspect it could mean something like "I just discovered that I don't like to work in XXXX environment". Correct? I just read that Richard Feynman in his "Surely You are Joking" book that he complained to his professor that he has not been ...


2

Make sure you know yourself before doing anything drastic Three years is still pretty junior, so I wouldn't do anything drastic like changing jobs or careers until you've made sure you know what it is about maintaining legacy code that you don't like. For example, it's possible that you need to learn a new tool or technique, and that you can actually learn ...


6

Legacy maintenance builds the developer's desire for good practice I just want to add the perspective of a lead developer, because as a developer I agree with not wanting to maintain legacy code, but as a lead developer I do not advocate for any developer avoiding it. I'll use a practical example to make my case. As a consultant, I am often sent into a ...


1

After a few times I discovered that I begin "hating" some code base, I started researching why. And found out that it's because it has some drawbacks that are constantly bothering me and remain unfixed. The bother is thus building up and... So the way to elminate that "hate" is to identify and fix the things that are bothering you about that code! What is ...


2

There's a good chance you might benefit from hearing my story, so here goes. I was hired at my company to work on one particular project (partly because I was the only guy they interviewed that knew electronics at all, but that ended up being largely irrelevant). On having worked on it for about six months I came to the conclusion the architecture was a ...


2

Don't seek the comfort zone You totally underestimate how incredibly many totally inept people with a 3 year work experience record there is. There are loads of them. Ineptitude is a choice (or, lack of making one) that comes from staying in that oh-so-alluring comfort zone. Don't be there, don't even desire it. Being uncomfortable means opportunity for ...


6

Lots of great answers already, but adding my £0.02. Maintaining older software is more difficult than building something new, it's also a valuable skill in itself. Being able to jump into a codebase that has been around for years, with bad or no documentation and featuring lots of different coding styles from the many developers who worked on it is ...


22

I have wasted 3 starting years of my career. Is there any way to start over? You have not lost any years, you learned many things. http://norvig.com/21-days.html is providing a mind-provoking insight. And you need to read Bullshit jobs, it is mind provoking and covers quite well software development jobs, since most software projects (more than half of them)...


37

Basically, you've gotten yourself stuck where you don't want to be because you've been worrying about what other people expect of you. It's time to stop doing what other people tell you too, and to start the career path that you want to follow and be happy. Now, you have three years experience as a developer - it might not be the tech stack you want, and ...


1

I went through this for a long time. It became something unbearable. Unfortunately, work consumes most of your day time and it's very disgusting to wake up thinking you'll be around a lot of bad code. It's a bad feeling. I love to create and invent; that's why I became a programmer a long time ago. I'm not a genius either, brilliant but rather creative. ...


3

It depends on the company. In my last job, my company offers IT solutions to government and banks. So everytime it is a new tender and a new project. I belongs to development team, which takes part in bidding, designing and implementing projects. After production release, the maintenance team will take over and will only contact us with issues they cannot ...


7

My team currently maintains two products that came to belong to our company when our company bought out the original developers. The reason these purchases were possible is because the other companies were not doing well financially. I work on only one of the two products. Early on it was like being a taxidermist working on road kill. The original coding ...


8

tl;dr: Be honest with your employer. Tell them you're only interested in greenfield projects. Note however, that making this decision will significantly limit the work you'll get offered, possibly to the point that your services are no longer required. One of the most important things in professional software development is collaboration on a shared ...


1

Here is a strategy that you could use. But, be careful, this could put you in an unfavorable position with your manager. Tell them that certain modules are crap and need to be re-written from scratch, you are unable to band-aid them. He/she might find someone else, or let you re-write. If you can re-write, it is almost like a new project, you should be ...


2

Put yourself in the other shoes You know your manager, he listen to his team? Is a reasonable manager? Try to satisfy developers needs? Is communicative? This is very important, your manager has a role...get the job done, present results. And for that, someone has to take care of the legacy project. Does he has another replacement? Does he has another ...


4

It seems you clearly understand that your Project B uses fake scrum. It seems you competently resisted some fake-scrum nonsense (extra large velocity numbers) in your previous tenure on the project. That is excellent experience, even if it was unpleasant. You also noticed that you had responsibility (prepare code for test, for example) without authority (...


3

If you don't like what you're working on, then leave for another company. Programmers are in high demand. Make sure you find up-front about the types of working you'll be doing. I won't criticise anyone for leaving in your situation, it sounds awful. But if you were hired knowing you'd be working on this type of project, then it would be in poor taste to ...


27

My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this? No it would not be reasonable. Part of being a programmer is maintaining existing programs whether its adding/removing features or fixing errors. You were lucky to have worked on some projects that ...


16

You can always ask, but they can always say no, too. Unless you have it in your contract that you will only work on projects you like, they can put you on projects as they see fit. You could document the changes you would want to make (refactoring, writing documentation, ...) and the benefits for the company in terms of time gained through less bugs. Or ...


49

Yes it is reasonable to tell your manager you are not enjoying your work and to ask for something fun. It is also reasonable for that manager to ask you to stick it out. There is a job that needs to be done and the job can't be all fun all the time. A good manager will realize that they are burning your usefulness and willingness to work for them and will ...


150

Unfortunately maintenance is the rule when working in IT, very rarely are there new projects, and people get reassigned around projects regularly. And while the quality of the code you will have to maintain in your professional life will vary widely, they will never smell the same as a fresh 2-6 month old project. However, there are things you can do to ...


2

Consistency is a weak argument. For a person who doesn't agree with a particular formatting rule, it might feel like there's a problem with micromanagement or with a power-hungry architect. Formatting almost never matters - "it's like colors, some people like it red some other blue". The real benefit of automated formatting rules is that programmers don't ...


0

They are not allowed, except... The problem is that the employer is not allowed to see your private communication with others. Yes, they are allowed to see the communication of their company mailbox, but they are not allowed to see the possible private communication what you did there. If you did not sign some paper, that you won't use your company mailbox ...


2

This isn't meant to be a full faceted answer - just one covering an angle that hasn't been discussed all that much: Human beings are naturally standoffish to anyone classified as "other". The Robber's Cave experiment is a great illustration of this. They got a bunch of 12 year olds and put them into two groups - with each group not knowing about the ...


0

I will not go into the full theories on how to run a business and how to run a project. I will leave that as a homework to you. Below I will provide just-the-minimum needed for you to fix the presented issue. The other answers also have good insights into the the topic. Have an efficient project manager. They must make decisions about what will be ...


9

It sounds like your testers work in a separate "silo" to your developers, have little to no control over how features are developed, and also little to no control over whether or not a feature is considered "finished" All of those will affect their morale, and their effectiveness at being the gatekeepers that prevent your users from seeing bugs. Needless ...


0

Lack of systematic process appears to be a root cause From your description, it appears that what's causing the negativity is the lack of a systematic process to manage the project. This is turn may be causing the employees to lose motivation. What may help is to try introducing some structure in the work. Have well defined specs, use a bug database, make ...


Top 50 recent answers are included