I have different problem - I just can't code like The Kid anymore. I know I could in the past, I have the code to confirm this. Not anymore, I'm not able to.
And often I'm required to. My boss says: "just hack it quickly" or "it's one-shot script, just write it" and wants it done in an hour or so. And I can't do this.
I don't even know why I can't. I tried many times to "just code" and there's something in my mind that seems to be opposed to this. This "something" refuses to use unknown or not fully understood tools. It refuses to let ugly line of code be. I feel like I'm refactoring my "one-shot" scripts reflexively, without me noticing. And the worst thing is I do it continuosly - not when the script is finished and somehow works, but during writing it for the first time. I know exactly when was the last time I wrote more than twenty (Python) lines of code without breaking the code into functions and classes, caring about names and comments: in 2004. Tests came later, but now they are a reflex too.
And now what my boss wants done in an hour I write in three or four. Then he's getting angry and tells me to go clean and document some code or to implement something else, and I do, and it more often than not works and - I hear - could even be a pleasure to read. But then, few days later, he wants me to quickly convert something or export something or something like that and I just can't do it, unless I have previous script ready. Then he's angry again...
TL;DR - giving a damn is certainly a good thing, sometimes, but taken to the extreme can disturb your career.
Welcome to experience. Have you ever tried walking along the outline of a balance beam drawn on the floor? Jumping along it? Now move the balance beam 1' off the ground, still easy? try 5' and take away the mats. The difference between walking the outline and walking the beam is that you can 'see' the consequences of failure and you know they hurt.
Not surprisingly this happens in engineering as well. You start "just trying to get it done" and when you didn't know better you just wrote it. But now that you know better, perhaps you've been bitten by an unchecked return value or a fixed length array, so now you reflexively look for those things, you fix them, you refactor them. This slows you down, and your fresh graduate peers start thinking "the old guy is slowin' down."
The only way I've found to move past this to let go of the responsibility when your manager asks you to. The conversation you have is "Boss, I can crank this out quickly but the faster its written the more likely it will have some future problem in it." then write that into the comment "Boss asked me to hack this out, said he would take responsibility date - time" and then just write it and move on. Later if it screws up you don't worry about it.
But you can't just go all irresponsible on them, you also need to think about the kinds of things your doing and step up your game in terms of what some folks called 'design patterns' make an effort to capture the way you write the things you write all the time and train your fingers to spit out an 'ok' version from the start.
> The conversation you have is "Boss, I can crank this out quickly but the faster its written the more likely it will have some future problem in it."
Not entirely sure if this is satire or not but it's a genuine conversation that I've had with a few clients.
I call it "the spectrum of quality" conversation. I can write beautiful unit tested code that will not explode unexpectedly at 3am on a Sunday several years later...but it won't be (relatively) quick to get there.
Alternatively, I can rush through something that will have to be rewritten later and it'll only take me a few hours. Part of me dies writing that type of code but there's a time and a place for it.
You want to hit the afterburner? No problem, but there are consequences.
Technical debt. There's a time and place for it, but as financial debt you'll have to pay it back, with interests.
The best thing about the term, is that not technical people know and understand how debt works, so they can make a more or less informed decision and don't get that much surprised in the future when something need a big refactoring :)
That is exactly right. One the most interesting things I heard from a departing Google engineer was that he was declaring 'technical bankruptcy.' He was so fed up with hacking things together to make them work and not doing them 'right' that he just couldn't take it any more. So much of the way we work as engineers has analogs in finance that it stuns me some times.
I've felt the same way for a long time. At length I've finally decided that the fear comes from simply having been burned one too many times by that "one-shot script" that I was forced to "just hack quickly" becoming the freaking cornerstone of some business process and then weighing me down like a millstone around my neck for years afterwards.
I still get calls from a company I worked at more than a decade ago from people I've never even heard of over something I "just hacked together" one idle weekend as a demonstration of what was possible. Of course, its been hacked and bodged by others for a decade now so I don't know any more than they do at this point. It doesn't matter. My number is company lore and I'm their Gandalf.
Its just not worth it. These days, I do it well, or not at all.
If you're brash and "break things" and overall the situation turn out for the worst, if you're a kid, people will tutt and mutter and aww shucks who should have been supervising those rough edges on the young whipper snapper.
If you make the exactly the same mistake in a more senior positions / with grey hair, people will bring your qualifications into question - and I suspect those with political interests will try and leverage the failure against you.
A boss who tells you to crank something out in a hour won't remember (or care) about that detail in 6 months when you need to tweak that code. It'll just be your fault for writing bad code. Some clients do this kind of thing as well. They ask for a Cadillac, but can only afford the economy version. But - at the end of the project they'll still be expecting all of the Cadillac features and everybody will forget.
I can sympathize about bosses who are angry that things don't get done quickly enough, but there has to be a balance. If I was continually running into this I'd probably look for a new job where quality was encouraged.
That's a pretty interesting situation. I certainly don't think there's any "something" blocking you, I'd guess it's more of a vague feeling of caution that you're clinging to because you can't quite understand it. It's easy to get into these traps when it's something very important (like your job).
There are a few things you can try. You can create a personal project to explore the depths of "not refactoring", in hopes that you'll get used to it. You could also just try getting faster at your newer technique: writing code and refactoring in an hour instead of 3 (learning your tools like a master helps with this).
Your "sudden change" probably wasn't so sudden, but rather your experience with hitting the limitations of writing shitty code. Now you want to avoid those pitfalls in the future, but your boss doesn't seem to understand.
There's also plenty of places for you to go still, if none of the above works for you.
Edit: Creating a checklist of "the smallest chunk of work" can help you keep moving rather than getting stuck in tweakfinity.
A few suggestions based on my experience (I have the same problem sometimes...):
- "get it working and keep it working": get the minimal possible functionality working (outputting some result, even if there's utterly no error handling, input is ignored, all of the requisite services are stubs and any actual processing is faked), and make sure you keep it working -- if some refactoring is going to take more than an hour or two, plan it differently. This helps you get really quickly to a proof-of-concept (with TODOs everywhere in the code), and stops you from shredding it to "do it right" because that would break it.
- keep a list of your ideas of how to do it correctly, in a separate file. Yes, for the moment we're dropping the input directly into a SQL query and returning the result directly wrapped in a <pre> tag; for the real product we'll need parametrized queries, a dynamically loading JS table (to research), etc. etc.
- stay offline. Do not download libraries or frameworks, do not research the best way to do X, do not research the problem domain or look for open source projects that do similar things but are huge and will suck up your entire afternoon when you could have just hacked out a completely unreuseable, inflexible, one-time fix for this particular problem in an hour. Research is fun, it's interesting, and it's a way to avoid actually doing what you need to do -- half-assed work. If you really need to look something up, put it on a list, and give yourself 10 minutes to research everything on the list in a few hours.
Great advice, both from you and grandparent. First, I wanted to say that my boss is a programmer himself, much better than I am, and he understands the value of good code very well. But he's also a bussinesperson and knows when the product is much more important than the code - I trust him on this. At least consciously. It's really not his fault at all.
---
> You can create a personal project to explore the depths of "not refactoring", in hopes that you'll get used to it.
I can't. I mean - I do program in my spare time and have side projects, but if anything it worsens the situation: I have more time and no deadline, so I just tinker with the code until I'm satisfied. And I am satisfied, it's not like I don't know what "good enough" means, just that in personal projects that level of "good" is even higher, because I'm the one who sets it.
> You could also just try getting faster at your newer technique: writing code and refactoring in an hour instead of 3 (learning your tools like a master helps with this)
This is exactly what I'm trying to do - but it's a workaround at best, not a solution to the problem.
> rather your experience with hitting the limitations of writing shitty code
That's true - around that time I was part of a team that developed CRM system in PHP. It was meant to be 3-4 months project but in the end it was a year long nightmare of rewrites and feeling guilty for everything. I never did any postmortem or proper analysis of what went wrong (everything) and maybe that's why my attitude changed. I wonder if it's too late now?
---
> "get it working and keep it working"
This is a way I work most of the time. And refactoring I do and am talking about is always much quicker than an hour - I do it in very small chunks, one function or class at a time, not breaking the code. It's just that these very small refactorings pile up and in effect I have a nice script, which is documented and properly structured, and which took twice as long to write than it should.
> keep a list of your ideas of how to do it correctly, in a separate file
I do this with larger ideas. It's not that. Rather, I can't force myself to drop the input directly in the SQL using string formatting. I know I did it in PHP years ago and it burned me so hard I won't do it again. Willingly, at least.
> stay offline. Do not download libraries or frameworks, do not research the best way to do X...
> if you really need to look something up, put it on a list, and give yourself 10 minutes to research everything on the list in a few hours
This seems to be exactly what I need to do. It never occurred to me, but when I think about it I see that looking for "better" implementation in libraries eats large chunks of my time. And these implementations aren't even that good... Combined with mastery of tools, I think it can work. Thanks, I get the feeling that there is hope for me :)
> It's just that these very small refactorings pile up and in effect I have a nice script, which is documented and properly structured, and which took twice as long to write than it should.
Ah ha... one solution, then, may be to force yourself to stop when it's only just barely working, instead of continuing on refactoring. :)
I do know what you mean, I'm at that stage where I start to care more about process more than anything. It's not about getting the job done - it's about getting the job done efficiently and with as few mis-steps as possible.
It's easy to so get wrapped up in the process that you don't like to introduce risk of experimentation.
And often I'm required to. My boss says: "just hack it quickly" or "it's one-shot script, just write it" and wants it done in an hour or so. And I can't do this.
I don't even know why I can't. I tried many times to "just code" and there's something in my mind that seems to be opposed to this. This "something" refuses to use unknown or not fully understood tools. It refuses to let ugly line of code be. I feel like I'm refactoring my "one-shot" scripts reflexively, without me noticing. And the worst thing is I do it continuosly - not when the script is finished and somehow works, but during writing it for the first time. I know exactly when was the last time I wrote more than twenty (Python) lines of code without breaking the code into functions and classes, caring about names and comments: in 2004. Tests came later, but now they are a reflex too.
And now what my boss wants done in an hour I write in three or four. Then he's getting angry and tells me to go clean and document some code or to implement something else, and I do, and it more often than not works and - I hear - could even be a pleasure to read. But then, few days later, he wants me to quickly convert something or export something or something like that and I just can't do it, unless I have previous script ready. Then he's angry again...
TL;DR - giving a damn is certainly a good thing, sometimes, but taken to the extreme can disturb your career.