How to communicate to a boss who wanted a quick & dirty implementation that today is pay-day?

Question

Following a previous question of mine, in which I try to find ways to be quicker on expense of more dirty code, I think I managed to get more stuff done today, with the premise that when they break, neither I (nor others) will be able to do so again, and the fix will be slow & dirty.

I have now reached several situations in which the boss, being a boss, still expects things to be quick.

He is not dumb, and he is technically capable and very smart. He understands the value of order and infrastructure, and chooses to delay that in favor of getting things done now. When he does things, he does manage to be even more dirty, while holding in his head where things break, and what he can handle later. Despite trying my best, I currently can't.

How can I deal with his expectations of me, which I sometimes find unrealistic? From his perspective they are realistic, also backed up by another developer who is able to work this way. I view her as a genius, remembering absolutely everything from years ago, and being very fast coming up with hacks.

Both their codes are horrible: adhere to no standards, using no existing infrastructure, and many times containing bugs which are only encountered later.

I need a way to communicate being just an ordinary human, who thinks in an organized manner, unlike them, being able to think in some different way. At least until I get used to another way of thinking.

There is also a performance review looming, in which I already know the verdict: "Your work is of very high quality, but you are slow. We need a different balance of you [and we can't tell you HOW to do that {I asked multiple times}]"

From the comments, the gist of the question:

I want to communicate to my boss that the reason why I cannot provide a quick solution to a problem is because of the technical debt that has accumulated from previous quick and dirty solutions [created mostly by him], though I have a coworker who is capable of doing quick and extra dirty solutions in these situations. Result being my boss thinks I should be able to do likewise.

What I tried

1. I tried to explain that when hotfixing, it becomes very hard to understand the source of problems, thus costing more time, not even in the long term.
2. I tried to prove that stable code saves time by actually writing it.
3. I tried to show that if we work together, one of us can do work for everyone instead of all of us working solo ad-hoc.

He replies: "We are building a ship after we are already in the ocean ." [True]. He doesn't see the code that doesn't make problems, he sees code that does. So, when I try to automate things and introduce a bug, it is a problem, but if I had done it ad-hoc and introduced a problem, it's fine b/c I tried to save time.
He doesn't buy in to the working together frame "until we have a stable workflow [how? we aren't building one!], at which point automation will make sense".

He is very startup-minded.

Answer 1

Reframing Unreasonable Expectations

This is a tough situation because your boss expects you to do X which is beyond your capabilities to do. Meanwhile your boss and coworker can do X, and so your boss expects you to do X too. In this case X is being able to write quick and dirty solutions in a code base that already has a very high level of technical debt.

That skill is rare. There are many more common skills that all engineers should have, but what your boss thinks is normal is a very specialized skill that few engineers have or develop. It is extremely hard to convince someone that is in this mindset they are not the norm.

Mean while you have skill with organizing code and reducing technical debt, which is a very valuable skill, but that is a long term payoff skill. Your boss does not care about long term payoff and thus does not care about the value you are contributing by exercising the skills that you are good at. As such, do not focus/communicate what you cannot do, instead focus/communicate what you can do, but frame it around something that your boss cares about.

So the first step is: What does your boss cares about? Your boss likely has several things they care about even if they do not say it nor admit to it. I do not know what they care about, or what will get their attention so I cannot answer that question for you. Once you have that then look at your skills and figure out how your skills mitigate those challenges, concerns, or worries. Then shape all your conversations with your boss around that. some example things:

Bus Factor and Reality

What happens if your genius coworker is out sick for a week? What if they get an awesome job else where and put in their 2 weeks notice? The reality is that engineers move from company to company. When a new developer joins how will they learn what the previous engineers left behind? The boss is thinking short term but is not thinking of what happens when the people who are capable of doing those short term payoffs are no longer available. I would then focus on how my work is allowing any developer to be hired and immediately be able to contribute.

Lost Revenue and Customers

Has the company lost customers or revenue because of these constant fires? By preventing problems before they become fires you can prevent upset customers leaving horrible reviews or shredding contracts.

Final Thoughts

It is very important that you do not force yourself to conform to impossible expectations that will not help you when you eventually have to find work at another company. So when your boss says at the code review:

Your work is of very high quality, but you are slow. We need a different balance of you...

Respond with something like this:

The quality is necessary since that system deals with customer credit cards and so one error in there can result in all of our customers payment information being stolen which would result in a huge lawsuit that will sink this company. And I love my job and care about this company too much to let something like that happen. It would be like letting my child ride a bike that I know someone did a second rate job of assembling and thus know it is not safe to ride.

If your boss does not agree with your risk assessment, get that in writing so that if or when it does happen you have your rear covered.

Answer 2

I have other thoughts than those mentioned in the current answers (as of my writing of course).

As you explained in detail, quick and dirty code which will last long enough to call it "never-ending".

They are asking you to become like them (better at hacking/dirty code and fast) yet this skill is not that great and greatly looked down upon in many companies, especially self-respecting ones (including start-ups).

In my honest opinion, there is not much benefit for you to "get better" at these skills they are requesting. You are better off in another company that is commited to best practises and improving code quality and maintainibility, and learning from them. Also what is the pay rise going to look like, in most cases very little.

I suggest you find another role and forget about pleasing the boss, it's just not worth it in this current context that you have mentioned. Keep it peaceful, don't be upset, let the annual review pass and you miss out on the pay rise (meanwhile the other developer gets it). Keep your cool and move on.

Answer 3

How can I deal with his expectations of me, which I sometimes find unrealistic?

and (from comments)

Thing is, you reach the 20 part in 2 weeks, and then what? Then you have to tell boss that "that small 20% part is gonna take 4 times what the old big chunk took"

Makes me think that this is a matter of perception (and communication) of the actual difficulty/time of each feature/task to be done (versus the difficulty/time boss thinks it takes). This misconception may be due to lack of sufficient granularity of the tasks/features. For example, let's say we have these tasks in our Java backlog project:

• Create POJO class for FootballPlayer
• Crete POJO class for SoccerField
• Create POJO class for Ball
• Implement and test game logic (goal, fouls, events, etc.).

Should we say that, as we have 4 tasks, each one will take 25% of the time or effort? Nope. In this example, creating POJO classes is trivial (some IDEs can create this automagically with wizards or refactoring). Most of the effort and time will be consumed by the "Implement game logic" task. This task is actually the "80%" of your project.

We can now see how granularity may affect our perception of tasks and their difficulty. Perhaps this is what is causing a misalignment on the expectations your boss has on projects and the development pace. More granularity will make us realize the real weight of the project, for example:

• Create POJO class for FootballPlayer
• Crete POJO class for SoccerField
• Create POJO class for Ball
• Implement and test game logic (goal, fouls, events, etc.). Breaks down into:
  • Implement event polling logic for player movements
  • Test event polling for players
  • Define and implement fouls and their conditions/rules
  • Test fouls logic
  • Implement event polling logic for Ball movement
  • Test ball polling logic
  • Implement goal logic and conditions.
  • Test goal logic
  • (and more surely)

Now we have 11 tasks. Should we say that each one should take 1/11 of the time? Perhaps no... but surely this is more reasonable than what we naively though before (now, our "Implement and test game logic" is 8/11 = 73% ~ 80% of the tasks).

Thus, I think that with more granularity on your tasks listed, you will be able to better communicate and align expectations with your boss, and remove some "dirty" from your "quick".

Answer 4

Agile

---

As a Product Owner consultant and former developer, I find your question interesting, as it seems to almost be a problem about Agile development.

I'll try to help you understand the potential thought process of your boss based on your question, and hopefully this will help you communicate with them and resolve your problems as well.

Your boss is a Product Owner

---

Hey says, "We are building a ship after we are already in the ocean."

He understands the value of order and infrastructure, and chooses to delay that in favor of getting things done now

Your manager is working in the capacity of a product owner. He has stake in your product. His job is to think from the perspective of generating product value, rather than technical value. He is trying to push out the product from an Agile view, with the focus on delivery rather than technical debt, documentation, etc.

Communicating with your boss

---

I need a way to communicate being just an ordinary human, who thinks in an organized manner, unlike them, being able to think in some different way.

It sounds like from your question you have already approached the situations from a technical debt perspective. However, your boss still feels product trumps technical debt.

Instead, would it make sense for you to discuss with him from a product/user perspective?

Let me give an example:

---

You feel there is a need to start work on implementing an automated test framework. However, your boss will shut this down if it is communicated as an enabler for future. But what if, you communicate this from the user/product perspective?

• What if, by developing automation, this means devs and the boss could now theoretically demo to users and the team any feature you develop and have automated tests for?
• What if having this system use Gherkin, allows the boss to understand the work being done and what this means for the users?
• What if this means improved user experience, with less defects?
• What if the automation means that developers, as users, can now test faster and submit code faster?

As your boss seems to be focused on small deliveries, you could even propose starting with a very small automated test suite that does one single useful and valuable thing, and build onto that while the iron is hot.

Agile Teamwork

---

I tried to show that if we work together, one of us can do work for everyone instead of all of us working solo ad-hoc.

How can I deal with his expectations of me, which I sometimes find unrealistic? From his perspective they are realistic, also backed up by another developer who is able to work this way.

How is your team estimating user stories? Are they collaborative? If every story/task is individually estimated, this may be another thing causing issues for your team.

In Agile, responsibility lies with the team, not the individual.

If stories are not refined and committed to as a team, oftentimes they will have gaps. This includes lack of budgeted time for testing, documentation, automation, and technical debt.

This means some people may naturally cut corners, as there are no clear expectations on how the team commits to doing work. The best way to resolve this is to bring this up as a topic for discussion with your team and align on how to scope out and commit to work.

If every story has good enough descriptions of work to be done, agreed upon by the team, it's unlikely any one person would spend too much or too little effort on each story.

Summary

---

It may be worthwhile to think from the perspective of the boss, in terms of his deadlines and product-focus. This will help you figure out why he is pushing for product-oriented features, and let you better collaborate with him to bring in the enablers you and your team needs.

It may also be good to steer the team in the direction of teamwork, as this will help diffuse some of the concentrated responsibility, and also help the whole team work together better. This will result in less gaps in the work, and better estimates, both good things to have, even for your boss!

Hopefully this information from an Agile perspective helps you. Feel free to ask me any questions or to clarify your situation as necessary. Good luck!