5

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.

16
  • 1
    @BSMP I meant "nor", but I see why you ask. I think only the boss and that dev are able to make those hot fixes [not really hot, as they are doing it all the time], but mere mortals [other devs and I] are not able to.
    – Gulzar
    Feb 23 at 19:44
  • 3
    I'm trying to parse out what the actual question you are asking here - you've asked on another SE about how to deal with the pressure from a Coding PoV - but it sounds like this isn't sufficient. If you are asking us how you can think differently, I'm not sure we can help. Reading and re-reading your question all I can think of is 'perhaps this isn't the right work environment for you' - and there's no shame in that. I'd suggest a re-write of the question to focus exactly what you want help with and for it to be something we can answer. Feb 23 at 20:02
  • 2
    @TheDemonLord I highlighted in bold the question that OP is asking for better clarity.
    – DarkCygnus
    Feb 23 at 20:16
  • 2
    If someone isn't willing to accept that they're being unreasonable, you can't fix that for them. You can only be able to deliver the unreasonable ask, or try to get into a situation where you no longer need to satisfy them. It sounds like you are unable to achieve the former, so...
    – keshlam
    Feb 23 at 20:38
  • 2
    @keshlam - That's a much better way of phrasing it - which is why I'm struggling to come up with an Answer - I'm almost tempted to VTC - but I think with a rewrite there might be a good question. Feb 23 at 20:51

4 Answers 4

2

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.

4
  • I like this answer a lot, and will likely accept after I let it sit for a while to maybe get more opinions. I didn't like the last part - it is not about covering my ass, it is about having a nice work environment, which I otherwise very much like.
    – Gulzar
    Feb 23 at 22:20
  • @Gulzar: you should take the last paragraph as the ultimate move, because you never know what's next. And paper trail is everything in this case.
    – OldPadawan
    Feb 27 at 5:49
  • Writing bad, unmaintainable and dirty code has nothing to do with engineering. They don't work like that. It's rude to even assume it's part of an engineer's job.
    – red-shield
    Aug 23 at 8:49
  • @red-shield Writing low quality code does have a role and place in engineering, admittedly a very small place. Writing bad, unmaintainable and dirty code is easy and fast. This has two uses: Rapid prototyping/proof of concept to determine viability (with the intent to throw the code away), and the meatball surgery equivalent in engineering, where rapidly getting a fix will prevent loss of life or further property damage. In the latter case you can worry about cleaning up the code after the emergency is over.
    – Anketam
    Aug 23 at 14:32
1

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.

0

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

8
  • I think you are missing the dirty point here - as I see it (only after the work started, of course), some tasks must happen before others. They are the "clean-up" tasks, which physically prevent the "quick" from being done. In your tasks are hidden tasks: "Make old tests run again [breaks to what?]", "Find out in which dataset the data is", "Clean up that dataset so that undocumented requirements of ad-hoc script hold", and so on. I can't even come up with those before starting. They are in some people's heads though, and for them it is "just write ad-hoc 10 lines to fix".
    – Gulzar
    Feb 23 at 21:15
  • This could even be as simple as a task expected to be "use some function to achieve something", but only later find that said function now needs some new parameter, which I find to originate from some 3rd party, that has requirements to run, which themselves require things. Cost raises from 1 hour estimation to a day. Boss solves it by hard coding for example, but this breaks code elsewhere, which can no longer be fixed with hard-coding or original feature breaks. So the last person has to fix both places.
    – Gulzar
    Feb 23 at 21:22
  • "I can't even come up with those before starting" - then perhaps a better effort should be done to try come up with them beforehand. Or include a "unforeseen tasks" task in your time/effort estimation... You situation is clearly a Software Dev one and a Workplace one... my answer here contemplates a Professional/Wokplace approach with the hope of you getting another POV... more technical approaches correspond to you Software Engineering post I fear. I reckon that this situation is not trivial, and is something that happens frequently in the Software Industry
    – DarkCygnus
    Feb 23 at 21:23
  • 1
    @Gulzar also have in mind that a possible answer to this situation is: your boss has unreasonable expectations about the trade-off between quick/dirty and slow/clean :/
    – DarkCygnus
    Feb 23 at 21:28
  • 1
    Will edit soon with what I tried, have to articulate that first.
    – Gulzar
    Feb 23 at 21:28
0

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!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .