Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
159

I think the problem is the task: "I have been tasked with teaching other teams a new codebase". You have been given the wrong job, or maybe misinterpreted the job you've been given. By presenting at the code level, you invite code level thinking. Start at the system level and present the design and the design choices that were made. Don't allow extended ...


147

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

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


135

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.


96

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


86

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


81

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


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


70

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


69

What do you say in a code review when the other person built an over complicated solution? You say: "you built an overly complicated solution." So then I suggest that he delete all the unnecessary complexity. The answer I usually get is "well it's already done." If it's too late to change anything, why are you doing a code review?


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


66

"Park them". At the start of the lesson, explain what you are to discuss, and clearly explain what is considered Off Topic. If you are asked a question that is clearly OT, say so and move on. If they come back to it, write the question on a whiteboard (This is critical) for later discussion and move on. At the end of the lesson, when they are on their own ...


63

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


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

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

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


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


47

Comment Well Should you lower the skill of your code? Not necessarily, but you should definitely raise the skill of your comments. Be sure to include good comments in your code, especially around the sections you think might be more complicated. Don't use so many comments that the code becomes hard to follow, but be sure to make the purpose of each section ...


45

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


44

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


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


39

You are catching some heat here in the other answers for your decision to "do something" about this guy, but I fully get what you are saying. If the other team members "would all prefer to be coding, rather than doing these more mundane tasks" then they are going to be annoyed that you are rewarding the bad performance of the poor communicator by giving him ...


38

Rule #1: Don't ask to ask Rule #2: Behave as you would do in a real life conversation Rule #3: Be patient. If there is no activity, it usually means that no one has read what you wrote yet. If no one responds, they don't know or didn't notice. You can re-try after a while, or ask if anyone has any clue with regards to your question x minutes ago. Also, ...


36

You don't. I see this question and all questions like it as a bit of a dead end. You can't "convince" people of anything. If they aren't already aware of things like this or investigating it, chances are they don't give a flip. And no amount of data will convince them otherwise. Change must come from within. You can lead a horse to water but you can't make ...


36

how to explain that you've chosen to use one technology rather than an equivalent one for the reasons related to human resources, without giving the impression to be unprofessional or to not care about the project? Well. You say just that: In terms of the requirements for this project, technology X and technology Y are equally suited to the task, so ...


35

It seems you are looking for shortcuts not to try out the "purest naive implementation" first, and directly implement a "more sophisticated solution because you know beforehand that the naive implementation will not do it". Unfortunately, this will seldom work — when you do not have hard facts or technical arguments to prove that the naive implementation is ...


34

If a start-up immediately rejects you, an otherwise outstanding candidate, for lack of online presence, it would be a strong indication of questionable hiring practices of the owners of that start-up, and so you should be glad that they did not hire you. I worked for three start-ups over the course of ten years, and every time a major part of deciding to ...


34

First, be clear on the specific steps that management should take. "Give your programmers more breathing room" is too vague, not actionable, and not measurable. Second, identify the actual problem. Why are your programmers pulling all-nighters? There's always a root cause or causes, and that root cause does extend beyond "we don't have enough time get ...


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