Top 10 Lines: Developer Edition


Behind every great developer is a treasure trove of unforgettable moments with customers, clients, supervisors, or managers. While much of a developer’s time will be spent behind the screen deep in coding, there will always be times when you need to interface with your customer. Without further ado, here are the top ten things you are guaranteed to hear at some point in time in your career as a developer.

10. "You're the new developer, right? Nice to meet you! I'm sure you can't wait to get started coding…"

Many managers or customers might have the expectation for new developers on a team to be able to contribute code on day one. However, this should not be the case. Developers should never commit code to a program or system that they are not fully certain they understand enough. While it is your responsibility, as a developer, to contribute to the project, it is also your responsibility to contribute thoughtful, correct code.

9. "Could you give me a quick status update on the project?"

There’s nothing wrong with the question itself except for the issue where, if you’re deep into trying to fix a bug or solve a problem, it can be cumbersome to reset. Developers ranging from novices to subject matter experts need to be able to learn the lingo of their office to come up with the right answer. For example, if a developer is asking a fellow developer for a status update, this is a no-brainer: no technical conversion to layman terminology needed. However, if the person asking is your manager who is only asking out of curiosity and only has a few minutes to spare, you need to give enough context to not overwhelm them.

Also, this is a good chance to give a shout-out to the dilemma of the maker’s schedule vs. the manager’s schedule [link]. Basically, the makers (programmers, developers) operate on blocks of time that are significantly longer than a typical manager. They need to dedicate more time to a product whether it involves debugging or focusing, developers often need multiple hours in a relatively uninterrupted time block to do their job efficiently. On the other hand, the managers (managers, owners) often operate on hour-blocks of time. They tend to divide their day in a series of meetings. The dichotomy here is that managers often want to assist or help in the development process but it often clashes with a developer’s inherent time management efficiencies.

8. "Just give them what they want; we'll worry about potential issues later."

Customers love it. Project Managers are cautious about it. Developers fear it. This is a constant misnomer in agile—should we, as developers, prototype and develop working software even if we know it could be a refactoring nightmare or an O&M abomination in the long run? Or, should we try to explain to the product owner or the customer some of our concerns? There will never be a truly “right” answer, as that is always in the eye of the beholder. Be forewarned!

Photo by rawpixel on Unsplash unsplash-logorawpixel

7. "What do you mean we can't fit in this feature mid-sprint? I thought that's what 'agile' was all about?"

Priorities change all the time. That’s just reality. One of the ideas behind agile—the constant customer communication—is also, unfortunately, one of the places where developers experience the most heartache. When you hear this statement, it is once again a case-by-case basis on how you should respond. Simple bug fixes (should they be considered ‘features’) can sometimes be accounted for in planning. However, large shifts in priority involving a feature that needs system or architectural considerations will need to be put on hold and discussed.

Let it be known that agile is all about change, but that does not mean it has to come to chaos. Changes, if they turn out to be substantial, need to be communicated to developers during a sprint planning phase to make it an orderly process.

6. "I know we're six months into development, but I heard that Company XYZ is using AI and VR in their app. Could we do that?"

What hurts the most is being the one to tell the customer or manager that some modern technology they just heard about is probably completely irrelevant to the project at hand. This is one of those “buzz-words” at its finest moments. As a developer, you will have to reserve your initial opinions and express your feasibility concerns. One of the critical responsibilities of developers is to handle the technical aspects of a project. Customers definitely need to be involved with the vision and requirements, but often times the technical methods in which that vision is fulfilled is best left to developers.

5. “What do you mean it’ll take this long to make this change? The previous developer did this really quickly.”

It’s always tough to defend your time estimates to a customer when they have a previous developer comparison. Additionally, it can seem unfair to be compared to somebody who might’ve been more skilled in that specific area of the application. If this ever happens to you, you will need to explain in detail the concerns or roadblocks you will face during development. Nobody is perfect nor will you ever know everything you need to know about a system or its technologies, but with enough time it can be done.

Photo by Olu Eletu on Unsplash unsplash-logoOlu Eletu

4. "Why do you need to 'refactor'? The system is in production and works--we need to be adding new features!"

Refactoring code and making performance improvements will greatly reduce O&M time and expense in the long-run. Yes, obviously there will be features that take the utmost and highest priority, but that does not preclude refactor from its importance. Over time, many applications tend to accumulate a lot of code that can be improved. Whether it’s unneeded, circular, or confusing logic decision-blocks, inefficient loops, or redundant code, refactoring can make a system much simpler and reduce learning curve for newer developers. For a more in-depth analysis, Stephen Mouring provides a great narrative on refactoring here.

3. "I think we're getting too in the weeds on this requirement... Let's continue next week on the discussion with a meeting?"

Ever get tired of hearing the term “too in to the weeds?” Find yourself irritated at yourself because it is now part of your vocabulary? When people get tired or can’t keep focus (happens to everyone), the default answer is to talk about it as a larger group in the future. Meetings aren’t for everybody, but do not be surprised if others do not mind having meetings (referring to the maker’s vs. manager’s schedule). As a developer, the main goal of any meeting is to ensure that your technical questions and concerns are answered or relayed.

2. "Welcome to the team! I know it's going to be a little tough getting into the groove, but you will at least have some other developers to talk to. It would be in your best interest to pick their brains so you can get off to a great start!"

Guaranteed that if you ever work in a team and find yourself needing to learn the project’s architecture or stack, you will be told to “pick someone’s brain.” There’s nothing wrong with the idea of it but hearing it so often can make anybody groan. Knowledge sharing is very important, and this statement is just one of the ways to express the idea. However, it can be a little bit concerning to a new developer if this is the only way knowledge on a product is passed down. While asking for full documentation, support, and commented code can be quite optimistic, it can be discouraging for any new developer to find a codebase that isn’t self-documented or easily understandable.

1. "This change shouldn't take more than a few minutes!"

All I have to say to this is… “too soon?” When the customer asks you this, never outright tell them “no.” However, it is more than appropriate to express that there could be some difficulties and roadblocks to any new feature or change. Never fully commit to agreeing to any “quick five-minute change” unless you are certain it can be done within time. Developers can express their concerns and opinions—if the team believes it can be done in time then any additional feature outside of what was planned is simply a bonus.

Photo by NeONBRAND on Unsplash unsplash-logoNeONBRAND

And that’s it! Have a specific line that you know of that didn’t make the list? Let me know! Email me at [email protected].