Hot answers tagged

148

Stop doing the 80 hour weeks. This is positive reinforcement. Because they are getting the product on time with expected costs, they are going to continue doing it, regardless of what it does to you. If they cannot budget time properly, then that's management's fault. Not yours. Let them miss a few deadlines.


141

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


140

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


130

Ok, here goes my take on this big and complicated topic. Pros for keeping your coding style: Things like x = x || 10 are idiomatic in JavaScript development and offer a form of consistency between your code and the code of external resources you use. Higher level of code is often more expressive, you know what you get and it's easier to read across ...


112

You don't hunt down a former collegue to tell him he made a mistake. You may tell your friend that he made a mistake. Whether he is a friend or a former collegue is up to you.


103

The trouble with those policies, (IM are only an example ; you could also quote firewall blocking some websites), is simple : they believe they can force people to work by cutting their distractions. Fact is, when one doesn't want to work, one will always find a way not to. At the end of the day, what matters is if the job's been done.


99

In general, is there a way to push back on this? If not for this release, what about in future? Of course, there is: Let them fail badly with this approach. Nothing teaches as well as failing. Make an estimation yourself before you start and show it to them. Then do your best, write good code, stop compensating for their stupidity with your free ...


87

It Depends When I was looking for a job a month ago, I didn't put a link to SO on my resume, but I did mention that I participate on SO and added a link to my blog that contains the SO "flair" on the About page. At that point I had about 3000 rep. I wouldn't try to leverage rep, but I would leverage intelligent participation. If you act like a moron on SO ...


84

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


82

Having been "the boss" and, as it turned out, actually better than my staff in all cases bar one - yes, he will be mad - or annoyed or frustrated and in any case, quite possibly, right in the first place. If you're genuinely better than him then you should be able to understand his proposed solution and to see why yours is better and then to explain why. ...


82

You and most of the answerers approach this as a communication issue between two colleagues, but I don't really think it is. What you describe sounds more like a horribly broken code review process than anything else. First, you mention that your colleague is second in command and it's expected that he'll review your code. That's just wrong. By definition, ...


80

I think most developers find themselves in this position at some point, and I hope that every developer who's felt victimized realizes how frustrating it will be when he or she becomes the senior and feels compelled to clean up code written by juniors. For me, avoiding conflict in this situation comes down to two things: Courtesy. Talking to someone about ...


75

Ask him to explain his code to you Tell him you've never seen X programmed that way before, and ask him why he codes it that way. Show him the way you code it, and tell why you do it that way (best practices, better performance, less chance of errors, easier for other programmers to read/maintain, etc). Be sure to prepare all your arguments in advance, ...


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


68

He's probably right. If the codebase is so monstrous, so gigantically complicated, so difficult to understand... what makes you think you can write something that does the same thing correctly? Generally a big refactoring is the best place to start - start ripping bits out and combining them into reusable chunks; tidy up the code so its easier to view; ...


61

It entirely depends on where you want to work. There is no universal answer to this. Many (all?) employers will google your name and look you up. You really should do that as well to see what comes back. The best way to control what they see is to have your own presence - something that will push any results that you don't want them to see way down the ...


60

From a guy who's used both SOAP and REST extensively... BOSS says SOAP is... richer and more expressive Anytime someone says a product is "rich" I want to become violently ill. I can't think of a more cliche comment to make about a technology or platform. Basically you're saying "I think this product is great, but I don't have any actual facts to ...


59

Our build/install is just too complicated. It can't be automated. I have walked onto way too many projects where the build, development setup, and/or the product installation "process" was a ton of manual operations. The result was either a poorly documented process with one guy who knew all of the steps that had to be done (and would mess up at ...


54

These four things were said to me by the same programmer: "I don't believe in encapsulation. There's really no point. All it does is add boilerplate and slows you down." "I don't do unit tests. That just slows me down." "Java is too slow. I need a fast language like C++." "I should really comment my code but it takes so long. It would just slow me ...


53

Here's the secret about programming: it is almost 100% communication. A significant part of that is communicating with a human; the rest is communicating what you've just learned to a computer. The latter part is the easier of the two. Computers do exactly what they're told and you are always in a position to test that what you told it is correct. The ...


52

This generally occurs because of a perverse incentive - the salespeople are being paid on commission, while the production staff is paid on salary. The salespeople have several levers to work with: features, cost, and delivery date. They have a strong disincentive to lower the cost, because this generally lowers their commission, so they tend to ratchet UP ...


50

I don't even try. If they aren't tech oriented enough to have at least a basic understanding of programming, I am only going to bore them with the details. Usually I just go with something very high level like "I create web sites" or "I write computer programs to do X"


50

"This is an emergency the change needs to go to production now, we don't have time for review, testing, or a roll-back plan."


50

When you have a big home theater and you add things, slowly but surely a big rats nest forms in the back. If you are often times replacing parts, sometimes its worth straightening all that stuff out. Sure, if you do that, it was working before, and it's not going to work better than when you started, but when you have to mess with it again, things will be ...


50

Yes, this is a One-time pad. If the key material is never re-used, it is theoretically secure. The downsides are that you would need one key per communicating pair of principals and you would need a secure way of exchanging the key material in advance of communicating.


48

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

You've more or less already answered the question: He's on probation He's not productive enough So, he needs to be made clearly aware that: He needs to be more productive or he won't survive his probation. He is liable to be more productive with a proper IDE than with a good text editor. A good IDE is not about giving up control over the code you write ...


46

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



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