Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuck
Buy Now
-
Just coded for ~14h straight. Started doing some super heavy code cleanup and refactoring. Almost cried when I saw my code from the past.
Maybe it's time to call it a day...
4 -
Client: This codebase is known to be ripe for refactor. We'll probably have you do that.
Me: *opens up codebase and notices inconsistent coding styles, bad design principles, and direct contradiction of accepted community standards for how to use that particular language*
Me: I suppose to start, do you guys have some coding standards I can look at to help cleanup the code in a way that is consistent with your other codebases?
Client: This one team was working on developing some, but they haven't touched it in a while. We don't really need them, though.
Me: Ok, then I'll do my best to make sure coding styles are consistent using my own knowledge. Why are you guys doing [thing that contradicts community language usage standard because it causes memory issues]?
Client: Well the docs talk about [similar x scenario], but don't mention [actual y scenario], so we decided to go our own way. It doesn't really matter, right?
Me: It can cause memory issues because you're largely bypassing some of the atomicity and garbage collection checks that come with the runtime by default. I'll change those to be safe.
Client: Why are you so concerned about these small things? We need to refactor the structure of the code! We don't have time for this!
Me (in my head): Because your codebase is unreadable and several of your issues could likely be fixed by following community guidelines.
Standards are important and should be agreed on by the Dev team using them. Community guidelines exist for a reason, even if they aren't 100% documented. These things may seem small, but they often make a world of difference when it comes to supporting your code and reducing technical debt. If you let your devs be cowboys, your code will be the Wild West.3 -
"I strive for code quality and maintainability. I actually do. And i will not work for a company that does not care about it and just wants something done as fast as possible.
The only time i will do something quick and dirty is if it's actually urgent. And even then with one condition - my next task will be to fix it properly.
I do not care about your deadlines. I will do my best to meet them, but not at the expense of code quality. I've seen too many projects fall into technical debt, where productivity is so low, that the only way to move forward is hire more people and start working on a project 2.0
And please do not lie about how great your company is, if it's not. These kind of things surface very soon, and you will have wasted both of our time, because as i said - i will not work for a company that does not care about code quality."
you think i'll ever get a job again if i put this on my CV ? :D10 -
As a full-stack dev who has been looking for a full-time role for over half a year now... How the fuck can it be so difficult to land a job as a dev? I'm a passionate, capable, and proven dev; it shouldn't be this hard.
And why the hell are coding/whiteboard interviews the de-facto standard for deciding if somebody is worthy of a role? Whiteboard interviews are as inadequate and unencompassing a means of determining the quality of a candidate as asking a dentist how well they know the organ structure of the human body.
I've applied to an endless number of positions, so far-reaching and desperate as to even apply to international positions and designer roles instead of developer roles (I've been a graphic designer for over 13+ years). Even with this, most don't get back to you, and the few who do most often just notify you of your rejection. On the rare occasion I land an interview, my chances get fucked up by the absurd questions they ask, as if the things they are asking about are at all an appropriate, all-encompassing measure of what I know.
Aren't employers aware that competent devs are able to learn new things and technical nuances nearly instantaneously given documentation or an internet connection? Obviously, I keep learning and getting better after every interview, though it barely helps, when each interviewer asks an entirely new, arbitrary set of questions or problems....
Honestly, fuck the current state of the system for coding job interviews. I'm just about ready to give up. Why the hell did I put myself through 5 years of NYU for a Computer Engineering degree and nearly $100K in student loan debt, if it doesn't help me land a job?13 -
My brain is melting.
6 hours straight of just Refactoring without a break.
Technical debt is real, it is a bitch, and so are clients to expect to 'see' changes every week.
Boss tells me we need to balance doing work on things the client can play with and the backend code that does it all... 😧ok....
'TODO: remove sample return and connect to backen' As far as the eye can see.3 -
If I hear anyone utter the words "technical debt" one more time, I swear to God, I will fucking kill them :-/
It's your fault your design smells like piss in the first place. It's your responsibility to fucking fix it. You can't just sit on your arse all day, coming up with new, "innovative" ideas that will build up more technical debt :-/ it's making the life of everyone around you, a big, irreparable mess.10 -
SQL injection holes everywhere... The original author of the product put concatenated SQL queries throughout the whole application. If it's not the client asked for a penetration test, we as developers wouldn't even be given chance to fix this shit.
I'm actually glad to have the chance. I can't live seeing them every day but force myself to ignore them.8 -
Marketing pushed deadline for release one week earlier. That sucks.
What sucks even more is that frontend was not ready, but our frontend guy promised to take a look over the weekend and finish it. Thats cool we might make.
What sucks is that he fixed one small issue on Sunday 9PM and left the whole thing unusable.
So guess who was googling till 4am how to do stuff in bloody javascript?
In the end, I beleive I did a decent job and we ca release some kind of alpha and get rid of my dirty hacks later. That's how you get technical debt.
Now lets see what my boss thinks about it and if we are really going to release it or if I'm going to kill somebody.6 -
Amazing how people misuse the term technical debt.
A bug is a flaw in your design/development.
Tech debt is a conscious decision/tradeoff, which is often tracked and removed as the product matures.
The difference is subtle. Avoid this mix up at least in written communication.10 -
No, I do not wish to work on your Scrum-managed project.
I do not wish to contribute to the Taylorism of my profession.
I do not wish to be an interchangeable cog in your software sausage machine.
I do not wish to be tracked by some pointless metrics like a call-centre worker.
I do not wish to bust my tight, cute ass to sprint after some idiotic management request that could have been factored in earlier.
I do not wish to obtain some piss-ant qualification that "authorises" me to do my job.
I do not wish to be party to your lie that technical debt will be avoided by refactoring---whatever the cost.
I do not wish to contribute to the death of software engineering to have it replaced by software development.
Agile? Sure. I can pick up the phone and talk to the client, users and fellow devs. After all, that's what it FUCKING MEANS. Communi-fucking-cation.
See that burndown chart? See your anus? Know what's happening next?
Fuck Scrum and every fucking bottom-feeder that is scamming a living by promoting it. You're killing this business.
Hugs and kisses,
Platypus15 -
Anyone else work in a codebase that is so deeply convoluted, that the only way to make new features work is to write new code in a similarly convoluted way?
Everyone wants to refactor our system, but we're a small shop with an insane amount of technical debt, so it likely won't happen for a long time. Any suggestions in the meantime? I feel like I'm spending more time figuring out how to make something work in our system then learning actual good practices.6 -
Coming up to (very) tight deadline..
Manager - "Stick in a temporary fix, if the data is mocked out it will do for the demo. We really want to show this feature."
Me - "Okay, I"ll pick up the technical debt after the demo."
*Changes are coded and rolled out*
Manager calls me over to his desk..
Manager - "This feature isn't bringing back real data."
Do these kind of people exist in all companies?
2 -
Every sprint, the beast grows.
Every sprint, we'll sort it "later".
Every sprint, we suffer more.
We warned them, but they did not listen. The technical debt rapture has begun.
-
I hate marketing department. They have no idea how much work is involved to make their pedantic "minor" and pretty useless changes. But instead of considering the technical debt something will cause, they just want it done.
When they say "it's just this, it's easy" I seriously want to strangle them.
You do it if it's so easy assholes!
If I tell you the framework we use does it a certain way and to change it means to track down and make changes to core across entire system that most likely will break other stuff for something bullshit minor visual effect they seen on a competitors site that has an entire dev team of at least 5 devs, not a single dev that also takes care of there stupid servers, plus doesn't use the same framework we do, makes me beyond rageful. And then when i finally get it done, they decide they like it better a different way! Fuuuuuck I hate you!
Decided I really hate marketers.
Sometimes I wonder if I made the right decision not taking the job offer.3 -
There was a sales manager who was raked with overseeing me and another dev finish a last minute request project. He said at one point to the other dev that he was mad at developers because we understood something that he would never understand.
This same manager would often sit in on estimation meetings and constantly say that we were estimating too high and needed to come up with faster solutions. When we would offer him with caveats of possible technical debt or unintended side-effects/performance issues, he'd want us to go with that solution. He would then complain that we were always wanting to work on technical debt and that our application was slow. He would also ask for very high level estimates for large, unscoped features/apps without any meaningful level of detail, then hold us to the high-level estimated date even after revealing additional features previously unmentioned.
We learned to never compromise on the right solution and to push back hard on dates without proper scoping. They didn't learn, so I and most of the good devs left. -
LPT: Avoid building any complex report/tool with Excel, because you will forever be fixing the damn thing!1
-
In my short career, I've seen projects become legacy before their first release. Hell, I've seen proof-of-concept apps turn into technical debt because to management as long as it works we won't rewrite it.
-
Writing clean code.
Writing useful comments.
Commit before experimenting.
Just anything to prevent Technical Debt. Just because it works doesn't mean it should be kept as is. Later down the line you'll need to add a new feature and you'll spend 2x more time fixing the things you took for granted. -
I need some advice here... This will be a long one, please bear with me.
First, some background:
I'm a senior level developer working in a company that primarily doesn't produce software like most fast paced companies. Lots of legacy code, old processes, etc. It's very slow and bureaucratic to say the least, and much of the management and lead engineering talent subscribes to the very old school way of managing projects (commit up front, fixed budget, deliver or else...), but they let us use agile to run our team, so long as we meet our commitments (!!). We are also largely populated by people who aren't really software engineers but who do software work, so being one myself I'm actually a fish out of water... Our lead engineer is one of these people who doesn't understand software engineering and is very types when it comes to managing a project.
That being said, we have this project we've been working for a while and we've been churning on it for the better part of two years - with multiple changes in mediocre contribution to development along the way (mainly due to development talent being hard to secure from other projects). The application hasn't really been given the chance to have its core architecture developed to be really robust and elegant, in favor of "just making things work" in order to satisfy fake deliverables to give the customer.
This has led us to have to settle for a rickety architecture and sloppy technical debt that we can't take the time to properly fix because it doesn't (in the mind of the lead engineer - who isn't a software engineer mind you) deliver visible value. He's constantly changing his mind on what he wants to see working and functional, he zones out during sprint planning, tries to work stories not on the sprint backlog on the side, and doesn't let our product owner do her job. He's holding us to commitments we made in January and he's not listening when the team says we don't think we can deliver on what's left by the end of the year. He thinks it's reasonable to expect us to deliver and he's brushing us off.
We have a functional product now, but it's not very useful yet and still has some usability issues. It's still missing features, which we're being put under pressure to get implemented (even half-assed) by the end of the year.
TL;DR
Should I stand up for what I know is the right way to write software and push for something more stable sometime next year or settle for a "patch job" that we *might* deliver that will most definitely be buggy and be harder to maintain going forward? I feel like I'm fighting an uphill battle in trying to write good quality code in lieu of faster results and I just can't get behind settling for crap just because.9 -
My boss's SQL schema has no foreign keys and he said he left them out intentionally because they should be handled in the application layer and they're a large performance impact.
This is a fresh greenfield project and he's already pre-optimizing for problems we don't have yet, on things that may or not be bottlenecks using ideas (e.g. foreign keys have huge performance costs on mariadb/auora) with no hard data or facts to back them up.
Let's start a new project with some technical debt!2 -
Me: Why are we spending time building reports for Support? AFAIK they never read or use them.
Boss: Seems they expect you to do it.
Me: Then what exactly are they supposed to be doing? All the issues seem to just escalate back to us.... We should just make sure issues never get into PROD
Boss: I agree, they're always firefighting... we gave them more funding so eventually they should catch up **Me: I highly doubt it, you should just stop hiring monkeys** esp. if we prevent PROD issues.
Me: Yea... we should prevent production issues because someone always has to pay off the (technical) debt and interest rates in PROD are very high6 -
What time do you get up on work days? I'm starting to think I should have me time in morning (reading, learning, coding my own things) before going to work.
I've think I've come the the conclusion that this job/team is sorta chaotic and tedious and there's no skill growth. Not learning anything new. Usually just something broken, integrate some new feature, build something that I've already built before but differently for this specific case. Nothing fun or challenging, or new.
And also tired of trying to be a "role model", make things right. I tend to like to keep things orderly, documented, well tested and clean but everyone else seems to just bulldoze their way to get whatever they need, leaving a mess behind... It's been like 2yrs already but the technical debt seems to be growing not shrinking...20 -
So I am finally plunging into continuous integration. If I make one more deploy script mistake, I've lost enough time to merit having learned a better solution than bash scripting calling git and rhc and py files I wrote. I have failing tests that are failing because they weren't updated after the million and a half urgent changes in the past 2 months, so it's time to act like I am a TDD fanatic and write the tests correctly. So much work. All from me listening to the constant req changes, listening to the urgency, letting non-devs get under my skin if you will. I'm optimistic in all the wrong places - I think I can write that by end of day let's try it. I'm lazy in the wrong places - I think that I can write that test later, because all I changed was XYZ (which took all night but I said I'd get it as close as possible didn't I?). And I think these handful of bash scripts are good enough to make sure I run tests? But remember, I didn't write the tests or I didn't go back and update them. Or the tests that fail, I'm too lazy. And so much of the tests, I would need to use, idk selenium for, and damnit if I really don't want to dig for element IDs to wait for every time I need an AJAX call.
Okay wow, I really did rant here. And discredited myself a bit lol I need to ignore the wrong lazy and embrace the right lazy. Protect myself from myself and from contributors. It really is, up to me now, to rescue myself from my bad habits. Bad habits perpetuated by clients urgency every day, to change things, that should have been finalized in November if we wanted a stable flipping system in January. It feels like the blind (client) leading the blind (me, when I do dumb shit like rush features out the door half tested).
Anyway all this came out, because I have been reading about continuous integration and stumbled upon this quote. And thought someone might laugh at the anachronism like I did
2 -
If you give the client a choice of:
- Quick and dirty solution which results in tech debt
- Better solution that would be cheaper in long run
They will always choose the first without fail..2 -
I no longer work for a startup company. On Monday I’ll start work for a real company, one that values project managers and their infrastructure. As a DevOps engineer, I value the IT resources that power my old companies SaaS platform. My old position is not being back filled and they’re hiring a full time dev instead of and Ops engineer. They have chosen to proceed with zero employees who know Azure or the platform their own software runs on.
Word to the wise when choosing to work for a startup. Ask these questions:
- Do they have a dedicated product manager/owner , who isn’t also the CFO?
- Do they value infrastructure and their IT resources ?
- Do they have decent powered laptops to work with?
- Do they have too much technical debt because they’re always building new features ?
- Do they work 18 hour days because they set poor work/life boundaries ?
- Who handles Support tickets , and what’s a typical support issue like?
- Do they have a branching and merging strategy? Don’t accept “we’re too small” as an answer! It’s a trap that they don’t want one.1 -
Time for a full refactor. Everyone can go home for three days while I unfuck every page and pattern.
-
Ideal dev job?
Working remotely for an established company on a modern but not immature stack with a small but non-zero amount of technical debt for a good but not great salary with 3.5 weeks vacation and ample sick time. Also good unit and integration test coverage and continuous integration.
Is that too much to ask? :) -
I love working on legacy products. You just need a good shower and possibly a therapist after.
- Sensitive data sent over the internet encrypted with DES (not even 3DES). Guess it doesn't matter that the key (singular, for the last decade) is basically 0123456789ABCDEF.
- Client databases with open default port, admin/admin superuser.
- Critical applications (potential for substantial property damage, maybe loss of life) with a single point of failure and without backup.
Suggestions, to slow down a bit with sales, so we have time to rewrite this steaming pile of crap are met with the excuse: be more pragmatist, this is standard industry practice.
Some of this shit can be fixed on my own time if my conscience nags too much, but others would require significant investment of time from multiple developers, which would slow down new business.
Guess the pay is ok, so that's something... -
Fucking damn! This program is so poorly built that it's racking up terrible amounts of technical debt. This should be fucking easier than this, but because of how closely coupled everything is I'm now having to suffer through this ungodly beast of code.
I was aiming for a nice top down model where things communicated straight down, but with each additional feature requested by my PM, there are things that are growing increasingly more difficult to build around.
I could rebuild the entire thing, but this is the culmination of 8 months of work!
GOD KILL ME PLEASEEE -
Recently installed SonarQube and its been amazing to see the level of code quality (or lack thereof)
Some projects have 30 to 60 days of technical debt and I found a few files with a cyclomatic complexity over 100. I’m still learning what the “good” numbers should be.
Yesterday, couple of devs were very proud they were going to start reducing the numbers, they started with one of my solutions that had 5 minutes of technical debt. Yes, 5 minutes.
DevA: “OMG…look at this…it has a cyclomatic complexity of 11…that’s terrible. I thought we were supposed to be professional developers.”
DevB: “And take a look at this, he used the double-slash instead of a triple slash for comments. How does any of code even compile?!”
Me: “Maybe we should tweak some of those SonarQube rules so they make more sense to our code base. We’re never going to use unicode, so all those string culture warnings should go away and code comment formatting? Who cares? Be happy we have comments. I think we should also focus on the bigger fish in that pond. The CRM project is one of the biggest and has a lot of improvement opportunities.”
DevB: “There you go again, don’t bring me problems, bring me solutions..ha ha”
DevA: “Yea, no kidding …hey…did you see the logger? OMG…the whole class is over 25 lines…we gotta split that up into smaller projects so it’s more manageable.”
It’s a good thing our revenue stream isn’t dependent on people getting work done.2 -
I have a folder in my project called Technical Debt. As of now it has the same number of files as the rest of the project.
-
"Do it right do it light..do it wrong do it long"
My old peewee football coache's sage advice on the pitfalls of technical debt..1 -
Demo Driven Development
Now let's hit some deadlines, add the tests later, and the technical debt will probably just be somebody else's problem. -
!Rant
How do I get into Technical blogging? I think I have a lot to say and it will probably vent my frustrations, especially on the need reduce technical debt...
and also figure out what m my ideal team would be...
But whenever I start writing (which is rare) I can never finish... Gets sidelined by other things...5 -
On a project that will crash and burn due to a badly projected date given to the business. I'm team lead and the Developement manager. I'm not sure how to save my career from this one. 22 years at this company and this may end my employment.
Can't change the date because the business has had it with deployment failures. Not enough time to do any of the technical debt and I'm not sure one if the issues has a solution.
Time to create a resume I guess. Been a really long time.
Let me know if you want a developer in Des Moines!2 -
Giving a short talk on technical debt at our monthly meeting tomorrow. I hope it helps people in my organization understand why we need to take care of all the quick and dirty work we do. I'm tired of people saying how long updates take and the reason is because we cause the problems.3
-
Adding "highly skilled in code divination and paying off bankrupcy-level technical debt" to my resume.
Thanks PHPepsi, you trained me good for this...1 -
Today, for a feature that doesn't need to be released at all, we had to choose between delivering 2 months later so we could pay the technical debt, or release on time with even more technical debt, and 96% sure this will kill the project.
Guess what?1 -
So, after having my mental breakdown with the 500k LoC Zend Frameshit PHFuck 5.5 with 0 test project, for a whole year; and after moving to a better job, I now inherited a React/Node/GraphQL project with a shitty architecture. It's so shit technical debt can almost be payed with actual cash... or flesh, ass-for-arch.
However, line test coverage is over 90%, so I guess it is an improvement.1 -
The term "technical debt" is poorly used. I hear folks of all stripes and roles proudly proclaim that they've "reduced technical debt" in some way. It's used as a catch all to describe some kind of supposedly beneficial change. I think it's just more software process word salad. Mostly because there seems to be some assumption that "Yay, that stuff that was changed is no longer a problem" when odds are that it will be changed again before too long for more "technical debt reduction". Software changes over time because the requirements change over time. I don't see the need for the phrase at all, and I think using it gives some false sense of accomplishment when really the constant change of code is the normal state.6
-
Join a team that understands technical debt and actively squashes it...
Yes I am having a bad day, or should I say month, because I have to work to pay down other people's debt... -
Company tool over a Magento shop from an internal solo developer. They made a new theme based on a bought theme, but the developer who started it is leaving. The 'developer' (yes, quoting it now) made a royal mess about it; rewriting core files, overwriting theme files, leaving JavaScript alerts all over the place, placing business logic in templates and defining CSS classes with functions in custom module block classes. I could go on for a while. After the first sprint we tried to convince the customer to do a complete rebuild, but we couldn't convince him...
The 'developer' has been hold on for now to give support on his crappy code and my next few months are filled with working in this mess without cleaning up the technical debt because we don't have enough time for that... FML1 -
I'm in a dilemma.
I started this job about 9 months ago and it's really not what I expected. I'm the sole developer in my department that handles applications built around our customer database.
Well it's pretty boring and there is a lot of technical debt with the source code since usually 1-2 people are taking care of it so they never had proper conventions. And we have super old applications running on legacy solutions like cold fusion 🤢
I also receive a lot of problem tickets that never contain enough information to actually do anything and the people don't realize I have no idea what they do or what their business processes are.
The upside is I'm paid very very well for this job > 100 in a place where cost of living is cheap. And when there's no work to do I can work on side projects.
It's really not fulfilling work and idk if I should stick it out. I also don't know where I would head next. There's not very many companies working on cool stuff. Maybe remote work?
Anyone else have a similar story?7 -
We were asked to go from a prototype iPhone app to a fully released application to the App Store in 7 months. This probably doesn't sound like a lot, but it was a communications application in a healthcare setting. We had to hook this in to corporate systems, write backend server side code, setup a 3rd party platform that handled the communication and utilise their framework for the app (which they sent us several versions that just didn't build). We had all of this and only 6 devs to do the work. 2 months in, we realised we weren't going to hit deadline unless we picked up more developer capacity.
Normally, this would happen by hiring more devs.
Their response was to have all 6 of us work 60+ hour weeks and some weekends for the remaining 5 months until we managed to crap an application out to meet deadlines that sort of worked.
We then spent 2 years fixing it and cleaning up the technical debt caused from this process. Needless to say, I no longer work for them.2 -
Ok so first technical blog post/rant cuz I just reduced a lot of debt... Prolly gonna put this in an email to my boss (he says progress improvement is now a priority but there are some problems as listed below):
So last week, I spent a lot of time investigating db logs manually to figure out a prod issue: tiring, time consuming, and not very effective.
This week I built an app. It took a few days but having the time to design it correctly, it is very powerful.
So in order to really do process improvement, you need to have: dedicated the time, the problem solving mindset (the right people), and the understanding of what the problem is and why so you can build a good solution (time and people).1 -
I hate weekly demos. Why not wait until something is done and ready to show, and then schedule a show an tell?
Otherwise you're just racing around to get some half-ass, not working rubbish in to make things look good. Yet it probably doesn't work at all, and is filled with technical debt that will make it to production.4 -
I'll never finish this shit!!!
Whenever I close a task I end up creating one or two more I found in the way, it's like an infinite rollercoaster of technical debt and perfectionist-me throwing work at myself.1 -
The customer told us that we have had a good momentum lately and that we need to keep it so that we can finish on time. What makes me frustrated is that what he perceives as "momentum" actually is increasing technical debt and overtime work...2
-
Comment introduced by a commit 3 years ago before an empty function:
```
%% TODO determine if there needs to be something here or if this can be removed
```4 -
I need some advice to avoid stressing myself out. I'm in a situation where I feel stuck between a rock and a hard place at work, and it feels like there's no one to turn to. This is a long one, because context is needed.
I've been working on a fairly big CMS based website for a few years that's turned into multiple solutions that I'm more or less responsible for. During that time I've been optimizing the code base with proper design patterns, setting up continuous delivery, updating packaging etc. because I care that the next developer can quickly grasp what's going on, should they take over the project in the future. During that time I've been accused of over-engineering, which to an extent is true. It's something I've gotten a lot better at over the years, but I'm only human and error prone, so sometimes that's just how it is.
Anyways, after a few years of working on the project I get a new colleague that's going to help me on my CMS projects. It doesn't take long for me to realize that their code style is a mess. Inconsistent line breaks and naming conventions, really god awful anti-pattern code. There's no attempt to mimic the code style I've been using throughout the project, it's just complete chaos. The code "works", although it's not something I'd call production code. But they're new and learning, so I just sort of deal with it and remain patient, pointing out where they could optimize their code, teaching them basic object oriented design patterns like... just using freaking objects once in a while.
Fast forward a few years until now. They've learned nothing. Every time I read their code it's the same mess it's always been.
Concrete example: a part of the project uses Vue to render some common components in the frontend. Looking through the code, there is currently *no* attempt to include any air between functions, or any part of the code for that matter. Everything gets transpiled and minified so there's absolutely NO REASON to "compress" the code like this. Furthermore, they have often directly manipulated the DOM from the JavaScript code rather than rendering the component based on the model state. Completely rendering the use of Vue pointless.
And this is just the frontend part of the code. The backend is often orders of magnitude worse. They will - COMPLETELY RANDOMLY - sometimes leave in 5-10 lines of whitespace for no discernable reason. It frustrates me to no end. I keep asking them to verify their staged changes before every commit, but nothing changes. They also blatantly copy/paste bits of my code to other components without thinking about what they do. So I'll have this random bit of backend code that injects 3-5 dependencies there's simply no reason for and aren't being used. When I ask why they put them there I simply get a “I don't know, I just did it like you did it”.
I simply cannot trust this person to write production code, and the more I let them take over things, the more the technical debt we accumulate. I have talked to my boss about this, and things have improved, but nowhere near where I need it to be.
On the other side of this are my project manager and my boss. They, of course, both want me to implement solutions with low estimates, and as fast and simply as possible. Which would be fine if I wasn't the only person fighting against this technical debt on my team. Add in the fact that specs are oftentimes VERY implicit, so I'm stuck guessing what we actually need and having to constantly ask if this or that feature should exist.
And then, out of nowhere, I get assigned a another project after some colleague quits, during a time I’m already overbooked. The project is very complex and I'm expected to give estimates on tasks that would take me several hours just to research.
I'm super stressed and have no one I can turn to for help, hence this post. I haven't put the people in this post in the best light, but they're honestly good people that I genuinely like. I just want to write good code, but it's like I have to fight for my right to do it.1 -
"All Tech Projects Run Over Budget"
https://medium.com/@team_96861/...
I was on a nice streak of being calm for a while and then this article just dropped today. Fuck management and fuck whichever dumbass wrote this piece of shit.
Is anyone else pissed off at this? It makes it sound like software engineers are slow and never on time, and the main reason for a project's failure is the inability of programmers to meet deadlines. I find this a little sus, especially as it's written by someone in a management position.
I would argue that projects fail because:
1. Management takes the very feasible timeline given to them and throws it out the window, opting to impose impossible deadlines instead, because FUCK your employees right?
2. Clients have requirements that can't be met (I agree w/ this from the article, but not the part about developers not accounting for issues--I always do this and everyone I know does this)
3. Technical Debt arising from when management tells the software engineers to *just do it this way because it's cheaper*
The calculator they made is nice but it's also quoting estimates that I and everyone I've spoken to agree with, so this is clearly not a software engineer problem, it's a fucking management problem. "Budget" = accounting's job.
/rant
That being said, the "take their quote and triple it" part had me dead...1 -
I find it very surprising that people at work are always reluctant to do code reviews. There are no standards in place and everyone is free to push whatever they want. There is Sonar but it doesn't catch bad logic. Don't know how are we going to deal with this technical debt.4
-
So our code gets released on Monday. Do you guys think I survive another week and not get fired?
It’s Friday. Survived another week. I feel like Monday is like my last day. I feel every day is my last day at work.
Well for many reasons which are true. Rewording my review so that I don’t get fired prematurely:
Sucks at Jira, does not do many code reviews, lot of technical debt. There is more... -
Sometimes I think computers and the work conspire to make me an alcoholic. Trying to rush the release and thanks to piled up technical debt it's taking ages. And as it is taking ages, other work is piling up so I would have to rush to something else without cleaning it up and will be swearing again next time. That gives me headache. And to cure it I need to drink. And drinking gives me different kind of headache. All those stupid endless circles are ruining my life!1
-
Management that understands and respects the true virus like nature of technical debt. Considers the implications of bolting on more features. Gives me a place at the table in decision making regarding these matters.
Don't settle for any less. -
Hasn't technology become magic - and we ignorant sorcerer's apprentices who can perform a video call to the other side of the globe perhaps while we understand only some bytes of the thousands software snippets that were piled up by us code monkeys to perform the miracle? ...
This however has always been the state of software (for us developers): that this house of cards needs constant care by our hands to not collapse - in constant fear we may preserve the facades while the number of components that interact, the sheer mass of code only allow for guesswork and hotfixes accumulating the technical debt. Yes, we have all that terms for that. The problems are known since the 80s or 60s, so we might be relabeling it once in a while, but mainly it is just: complexity.. or entropy.2 -
Does rapid application development methodology leads to more technical debt compare to other ones? With a factor like deadlines, a small number of team etc? 🤔
Top Tags
Weekly Rant
View