Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
331

Wow! Thanks for asking. Technically, like you, I guess I'm management, since I spend much more time communicating and leading teams than I do writing code.... but here's my take from both ends of the management horizon. Whether I'm a developer or a manager working for another manager, here's some stuff that helps in my communication with my management: ...


185

It is absolutely not normal for a group that size to be working without source control—the size of the largest group of programmers that can work effectively without source control is less than or equal to one. It’s absolutely inexcusable to work without version control for a professional team of any size, and perhaps I’m not feeling creative, but I can’t ...


160

The easy part first: there's a technical red flag in your post: I shudder at your mention of "mistaken estimates" - it's an estimate, it CANNOT BE MISTAKEN, that's why it's called an estimate. It can be off a little, it can be off a lot, that's why it's called an estimate. If you are taking estimates as gospel, that's going to be one of the main problems ...


151

Sorry to say this but, You aren't going to want to hear this, but he is not completely wrong. If you are doing work for hire for external companies as a consultant, and they are willing to accept the most slapped together thing you can do and don't complain, and are willing to come back over and over again for you to do more work, your boss is 100%...


141

You are really talking about technical debt. Maybe a metaphor would help your managers. I often compare the effect of technical debt in software to cooking in a dirty kitchen. If the sink and counters and stove are piled with dirty dishes and there is trash on the floor, it takes longer to make a meal. However, the fastest way to prepare the very next ...


112

I fail to see how they currently add value and is scheduling meetings, booking offsites and other administration works enough for their role? Don't underestimate the amount of interaction your manager does with other departments. They handle budgets, training plans, HR paperwork. They protect the developers from getting sucked into meetings with other ...


108

It may not be normal, but as Treb says, it's probably not that unusual As others have said, there are no valid reasons for not having source control in a company your size. So you need to identify and attack the invalid reasons: a) the main one is the status quo: "if it ain't broke, don't fix it". This is difficult: you could start pointing out all the ...


106

Actually, this is a very difficult question because there is no absolutely right answer. In our organization we have been putting better processes in place to produce better code. We updated our coding standards to reflect how we, as a group, write code, and we have instituted a very strong test/refactor/design/code loop. We deliver continually or at least ...


97

I'm afraid that I'm going to have to disagree with many of the answers to this question, as none of them have mentioned the difference between intrinsic and extrinsic motivation. From the Wikipedia page: Intrinsic motivation refers to motivation that is driven by an interest or enjoyment in the task itself, and exists within the individual rather than ...


92

"Now orders, without discussion, have come down that everyone is to switch to Eclipse." I think that this is the real red flag. Your team is the expert on software development and the one to be affected by the decision, and yet you did not get to say a word in the discussion that resulted in this order? It sounds like over-managing by pointy-haired bosses....


92

A genuinely terrible programmer can have sub-zero productivity (the bugs they introduce take longer to fix than it would take to just do all of their work for them). And a genuinely great programmer can do things that poor and average programmers would simply never achieve, regardless of how much time you gave them. So for these reasons, it's hard to talk ...


91

Sounds Like My Old Job (1 Sales Person, 1 Graphics Person, 2 Programmers) This used to happen all the time at my old job. I agree that sales drives everything. The shop manager (Skill Set: 80% Sales 20% Graphics) was constantly underselling features customers wanted. A 20 hour job would be sold at a 10 hour price because the customer wasn't willing to pay ...


81

Taking what you said at face value, and assuming that the seniors didn't spend their nights and weekends fixing or rewriting the code that you wrote ;-) ... ...there is no reason to stay where your work goes unrecognized and unrewarded. Caveat: do not take career advice from strangers on the Internet.


80

Things that seem to work well for me: Give meaningful work and encourage ownership - even when a problem arises, don't solve it, talk through it and give the person insights so they can solve it themselves. edit - addition - this was also meant to include - stay the heck out of details. Assume your people know enough to do the assignment without ...


77

It sounds like you are placing too much effort on having well rounded individuals and not enough effort on having a well rounded team. There is nothing wrong with being good at something--in fact, that is probably why he was hired! You should be thankful to have someone who is good at programming to begin with. You stated: ... it goes against my ...


76

I am going to go out on a limb here and say something that is not likely to be the answer you want to hear, but if you don't like management, your career path is going to be very limited. If what you like to do is code, and if you are really good at it, and you don't want to stop, then your career path is on a single trajectory: software engineer and then ...


76

Here's what you do: Let them know that the candidates they are sending you are all unqualified Give them your minimum qualifications Reject anyone who does not meet those qualifications. If they refuse to give you resumes of anyone who meets your qualifications, then you have done your part. Regarding ethics, you don't have a responsibility to replace ...


69

There's a lot of good stuff here but I feel the following need to be said.. ..Sorry to be harsh.. But this need to be said: 5 Years as a PM, and to not know what kind of PC a developer needs, is outrageous. To have a developer quit because of bad working conditions as your first real red flag, is insane. What I think you have is a Trust issue, more so than ...


69

Have you spoken to your development colleagues about this? How do you know they lack education? That's quite a sweeping statement and you'll probably find you're wrong. I don't think it'd go down too well if a new grad started meddling with processes without understanding why they're like that in the first place. Managers love processes and love tracking ...


63

It is reasonable that when you working together on a common project, that on every workstation you have all the tools available to edit/build/debug your software, and that the core tools for doing about 90% of the development are known to everyone in the team. That goal is harder to achieve if your team is growing and everyone uses his personal favorite ...


62

One thing I've realized in my career is that there is always time to do it right. Yeah, your manager might be pushing. The client might be pissed. But they don't know how long things take to do. If you (your dev team) don't do it, it's not getting done; you hold all of the leverage. Because you know what will really cause your manager to push you or your ...


57

Management won't change anything if they don't feel any pain. If you allow management to be hands off (by fixing things and being successful) then you will be expected to continue fixing things and being successful. After all -- from management's view -- things are fine. Stuff is getting done. You may feel stressed, but that's not what's important. ...


54

I have seen companies do this. They end up with angry customers. Customers have a habit to come back and ask for new features as soon as the app starts to make money for them or is integrated in their business flow. You will soon have to tell those customers that you can't add new features to the mess you created, because you can't handle the code base ...


52

It sounds like what you're doing is basically equivalent to a code review except that rather than providing feedback to the developer, you're making all the changes that you would suggest in a code review. You'd almost certainly be better off doing an actual code review where you (or someone else) provides feedback to the original developer about code ...


49

Ask Them What we want is not necessarily what they want For example, I would want a high salary, considerable equity, flex time, and a cash completion bonus for hitting each milestone. I have no interest in Red Bull, pizza parties, or trinkets. ADDENDUM: most important: keep your promises


49

This should be a surprisingly easy problem to solve. Have a second meeting with him. Tell him that you accept that it's probably your perception of reality that is at fault. Then qualify that with "however, if that is the case then we need to work together to improve my perception." Finally challenge him to solve that problem, so he doesn't feel micro-...


47

You've stumbled across something that plagues programmers everywhere at some point in their careers: this code needs to be refactored, there are architectural issues over there, this module is becoming unmaintainable, etc. Because of the present culture of your organization, however, you're being pushed to focus on work that only yields directly visible ...


46

Technical debt is like financial debt. You take it on (hopefully) strategically in the development of a program with the intention that it will be paid off in the future. Sometimes people make poor technical debt decisions (such as running up a credit card), but sometimes a certain amount of technical debt is just normal. Deciding not to devote the time to ...


42

Is there a social or technical solution to this? I suppose, but this isn't a problem. Your manager should know what you guys are doing. They should make sure that you're not doing a bunch of work that provides no value, or why non-ticket work was prioritized. There is no harm in this. In an ideal world, it will provide benefit, because your manager can set ...


41

Honestly - as an entry level developer with 1 year of experience - you might be overestimating your contribution if you are saying you've done 80% of the work. In large scale projects, a very large portion of the work involves requirements gathering. Testing, pricing, marketing, etc. also play a very large role. If, as an entry level developer, you are ...


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