Tag Info

Hot answers tagged

166

You might not like this, but don't use asperger's as a crutch. What you've written here is clear and succinct, so you've shown you can write prose. It doesn't have to be good, or even interesting to anybody but yourself, but just spend some minutes a day writing something about something.


139

Sorry to say this 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% correct. ...


138

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

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.


90

Consider the following: "I have aspergers disorder" No one cares. Seriously. If you've written any good code, we don't care about your personal life. If we knew you, we probably would care. However, we don't know you -- we only know your writing. "I don't know the first thing about writing interesting and engaging text". Neither do 85% of the bloggers ...


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


80

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


74

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


74

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


72

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


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


67

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


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


58

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


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


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

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.


47

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


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

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


46

The preference you observe looks like a natural consequence of recommendation clearly stated in GNU Coding Standards. It suggests to report bugs by email, as you can see in below quote (I marked bold the part that directly addresses your observations): 4.7.2 --help The standard --help option should output brief documentation for how to invoke the ...


42

I noticed that talking about TDD hardly works. People like to see raw results. Saying that "writing tests will reduce development time" is most likely true, but it might not be enough to get anybody convinced. I was in similar position (well, not as bad as yours), and it kind of resolved itself when people started working on my code (note: my code was unit ...


41

This may not directly answer your question, but it might lead you in an interesting direction. I think what you need to do is more related to selling them on the idea than explaining it to them. Sales is all about understanding what the customer's problem is and then showing them how your product (or development method, whatever) will benefit them. Each ...


41

We worst part of the core are untested (as it should be...). This is the problem. Efficient refactoring depends heavily on suite of automated test. If you don't have those, the problems you are describing begin to appear. This is especially important if you use dynamic language like Ruby, where there is no compiler to catch basic errors related to ...


39

What sets off the bells for me is whenever I hear a programmer - a professional, not a student - asking a question that demonstrates that they really dont have a basic knowledge of computers or their profession. For example: a web developer asking a question that clearly indicates they dont understand the difference between what runs on the server side ...


38

You say your method is "quicker to implement". That rings alarm bells to me. Code that is quicker to implement can, very often, be hard to maintain. He is your boss. Unless you stay there for life, he's going to be living with that code for much longer than you are. Perhaps his strategy takes that fact into account. Short answer: Insubordination is a ...


38

The Real Edge (tm) that mailing lists have is with less busy projects. In order for a web based forum to be successful, it needs a core of people constantly present who can respond to questions, provide suggestions, and moderate it. But if a board only has a couple posts a week or month, many people interested in the topic (be it an open source project, a ...



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