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
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I HOPED I WOULDN'T BE BALD AS MY DAD BUT AT THIS RATE I WILL BE HAIRLESS FROM TEARING IT OUT ON MY BLOODY OWN
I got hired for cleaning up a 2 year project of rushed spaghetti code , where they previously only had 1 programmer aND HE WROTE 37 THOUSAND LINES OF CODE!
OH WE NEED A NEW FEATURE?! LEMME JUST RESEARCH THIS COMMENT-LESS CRAP FOR MULTIPLE MILLENIA BEFORE I CAN GRASP WHAT THE FLYING FRICKIN FRIDGE CODE DOES
To top it off, I've about ONE MONTH LEFT BEFORE BETA RELEASE TO FIX THE CODE!
I'm super grateful for this job as it's my first programming job BUT I'M GONNA SET THE REPOSITORY ON FIRE SOON AAAAHHHHHH
HOW CAN YOU, THE PREVIOUS PROGRAMMER, WORK IN THIS ENVIRONMENT WHERE MOSTLY ALL FILES ARE +2000 ROWS OF UNDOCUMENTED CODE
OH AND JUST GOT A MESSAGE FROM THE PREVIOUS PROGRAMMER:
"You can just remove the unused code and refractor it some, izi"
IZI MY SHITTY POOP CAR
AAAAAAAAAAAAAAAHHHHH!!!
Now with that out of the way, how would you recommend handling a stressful release deadline?6 -
I recently joined this big MNC after shutting down my own startup. I was trying to automate their build process properly. They were currently using grunt and I favor gulp, so I offered to replace the build process with gulp and manage it properly.
I was almost done with it in development environment and QA was being done for production.
In the meantime I was trying to fix some random bug in a chrome extension backend. I pushed some minor changes to production which was not going to affect the main site. That was in the afternoon.
This Friday my senior rushed to me. It was like he ran six floors to reach me. He asked, did you push the new build system to production, I refused. He then went to the computer nearby and opened the code.
It was Friday and I was about to leave. But being a good developer, I asked what's the problem. He told me that one complete module is down and the developers responsible for them left for the day already and are unreachable.
I worked on that module multiple times last month, so I offered my help. He agreed and we get to work.
The problem was in the Angular front end. So we immediately knew that the build process is screwed. I accidentally kept the gulp process open for anyone, so I immediately rebuilt using grunt and deployed again, but to no success.
Then I carefully analyzed all the commits to the module to find out that I was the one who pushed the change last. That was the chrome extention. I quickly reverted the changes and deployed and the module was live again. The senior asked, how did you do that? I told the truth.
He was surprised that how come that change affect the complete site too. We identified it after an hour. It was the grunt task which includes all the files from that particular module, including chrome extension in the build process.
He mailed the QA team to put Gulp in increased priority and approved the more structural changes, including more scrutiny before deployment and backup builds.
The module was down for more than 5 hours and we got to know only after the client used it for their own process. I was supposed to be fired for this. But instead everyone appreciated my efforts to fix things.
I guess I am in a good company 😉4 -
There are three things in my workflow that I don't like:
1. Feature requests appearing out of thin air.
It's common to be handled work at 2pm that needs to be deployed by the end of day. Usually it's bug fixes, and that's ok I guess, but sometimes it's brand new features. How the fuck am I supposed to do a good job in such a short time? I don't even have time to wrap my head around the details and I'm expected to implement it, test it, make sure it doesn't break anything and make it pass through code review? With still time to deploy and make sure it's ok? In a few hours? I'm not fucking superman!
2. Not being asked about estimates.
Everything is handed to me with a fixed deadline, usually pulled off my PM's ass, who has no frontend experience. "You have two weeks to make this website." "You must have this done this by tomorrow morning." The result, of course, is rushed code that was barely tested (by hand, no time for unit or integration tests).
3. Being the last part of the product development process.
Being the last part means that our deadlines are the most strict. If we don't meet the deadline, the client will be pissed. The thing is, the design part is usually the one that exceeds its time (because clients keep asking for changes). So when the project lands on our desks it's already delayed and we have to rush it.
This all sounds too much like bad planning to me. I guess it's the result of not doing scrum. There are no sprints, no planning meetings, only weekly status update meetings. Are your jobs similar? Is it just usual "agency work"?
I'm so tired of the constant pressure and having to rush my work. Oh, and the worst part is we don't have time for anything else. We're still stuck with webpack 2 because we never have time to update it ffs.6 -
I've optimised so many things in my time I can't remember most of them.
Most recently, something had to be the equivalent off `"literal" LIKE column` with a million rows to compare. It would take around a second average each literal to lookup for a service that needs to be high load and low latency. This isn't an easy case to optimise, many people would consider it impossible.
It took my a couple of hours to reverse engineer the data and implement a few hundred line implementation that would look it up in 1ms average with the worst possible case being very rare and not too distant from this.
In another case there was a lookup of arbitrary time spans that most people would not bother to cache because the input parameters are too short lived and variable to make a difference. I replaced the 50000+ line application acting as a middle man between the application and database with 500 lines of code that did the look up faster and was able to implement a reasonable caching strategy. This dropped resource consumption by a minimum of factor of ten at least. Misses were cheaper and it was able to cache most cases. It also involved modifying the client library in C to stop it unnecessarily wrapping primitives in objects to the high level language which was causing it to consume excessive amounts of memory when processing huge data streams.
Another system would download a huge data set for every point of sale constantly, then parse and apply it. It had to reflect changes quickly but would download the whole dataset each time containing hundreds of thousands of rows. I whipped up a system so that a single server (barring redundancy) would download it in a loop, parse it using C which was much faster than the traditional interpreted language, then use a custom data differential format, TCP data streaming protocol, binary serialisation and LZMA compression to pipe it down to points of sale. This protocol also used versioning for catchup and differential combination for additional reduction in size. It went from being 30 seconds to a few minutes behind to using able to keep up to with in a second of changes. It was also using so much bandwidth that it would reach the limit on ADSL connections then get throttled. I looked at the traffic stats after and it dropped from dozens of terabytes a month to around a gigabyte or so a month for several hundred machines. The drop in the graphs you'd think all the machines had been turned off as that's what it looked like. It could now happily run over GPRS or 56K.
I was working on a project with a lot of data and noticed these huge tables and horrible queries. The tables were all the results of queries. Someone wrote terrible SQL then to optimise it ran it in the background with all possible variable values then store the results of joins and aggregates into new tables. On top of those tables they wrote more SQL. I wrote some new queries and query generation that wiped out thousands of lines of code immediately and operated on the original tables taking things down from 30GB and rapidly climbing to a couple GB.
Another time a piece of mathematics had to generate all possible permutations and the existing solution was factorial. I worked out how to optimise it to run n*n which believe it or not made the world of difference. Went from hardly handling anything to handling anything thrown at it. It was nice trying to get people to "freeze the system now".
I build my own frontend systems (admittedly rushed) that do what angular/react/vue aim for but with higher (maximum) performance including an in memory data base to back the UI that had layered event driven indexes and could handle referential integrity (overlay on the database only revealing items with valid integrity) or reordering and reposition events very rapidly using a custom AVL tree. You could layer indexes over it (data inheritance) that could be partial and dynamic.
So many times have I optimised things on automatic just cleaning up code normally. Hundreds, thousands of optimisations. It's what makes my clock tick.4 -
Continuation from :
https://devrant.io/rants/835693/...
Hi everybody! I am sorry that as a first time poster I am building 2 long stories, but I really like the idea of connecting with other people here!
Well, as I was mentioning before, I got a job in Android development and had a blast with it. Me and the developer clicked and would spend our time discussing PHP, the move to other stacks (I was making him love the idea of Django or Spring Java) games, bands and cool stuff like that. This dude was my hero, his own stack was developed in a similar MVC fashion that he had implemented from scratch before for many projects. It was through him that I learned how to use my own code (rather than frameworks and other libraries) to build what I wanted. I seriously thought that I had it made with a position that respected me and placed me in the lead mobile development position of the company. Then it happened. He had taken 2 weeks of unauthorized leave, which was ok since he was best friends with the owner of the company, those 2 along another asshole started it so they could do whatever they wanted. And I could not make much progress without him being there since there were things that he needed to do, that I was not allowed, for me to continue. When he came back I was quickly rushed to the owner of the company's office to discuss my lack of progress. The lead developer was livid, as if he knew that he had fucked up. He blamed the whole thing on me (literally told the owner that it was my fault before I was summoned) and that we lost 2 weeks of business time because I did not had the initiative to make progress on my own. I felt absolutely horrible, someone that I had trusted and befriended doing something like that, I really felt like shit. I had mad respect and love for this guy. It got heated, I showed the owner the text messages in which I showed him my pleas to led me finish the parts that were needed while he was away. Funny enough, he acted betrayed. After that it was 3 months of barely talking to one another except for work related stuff. He got cold and would barely let me touch the internal code that he was developing. It was painful. The owner kept complaining about progress and demanded that I do a document scanner for the company, which was to be attached to their mobile application. Not only that but it had to be done with OpenCV. Now, CV is great, but it is its own area, it takes a while to be able to develop something nice with it that is efficient and not a shitstorm.
I had two weeks.
Finished in one. After burning my brain and ensuring that the c++ code was not giving issues and the project was steady I turned it in...to their dismay. And I say so because I felt that they gave me such a huge project with the intention of firing me if it was not done. After that it was constant shit from the owner and the lead developer. I was asked then to port the code to the IOS version. I had some knowledge of it already so I started working on it. Progress was fast since the initial idea was already there and I really love working on Apple devices. And when I was 70% done the owner decided to cut me loose. At first he cited things such as lack of funding and him being unable to pay my salary. I was fine with that even though I knew it was not true. So at the time I just nodded and thanked the company for my time there. Before I left, he decided to blame it on me, stating that if they were not producing money that it was perhaps my fault. I lost my shit, and started using my military voice to explain to him how a software company is normally ran. Then I stormed out.
It was known to me, that the lead developer had actually argued against me being laid off. And that he was upset about it, we made amends, but the fact remains that I was laid off because the owner did not think of me as an asset, regardless of how many times I worked alongside the lead developer or how valuable I was actually to the company, their infrastructure did get better while we worked together, so I just assumed that he never actually did any mention of my value.
I lasted 2 months without a job, feeling horribly shitty because my wife had to work harder to ensure our stability whilst I was without any sort of salary. At this time I had already my degree, so all I had to do was look better. In the meantime I decided to study more about other technologies. I learn React, and got way better at JS and Node that I thought I could and was finally able to get another job as a full stack developer for another company.
I have been here since 2 months. It has been weird, we do classic ASP, which is completely pointless at this time, but meh. At this time though, I just don't really have the same motivation. Its really hard for me to trust the people that I work with and would like to connect with more developers.21 -
When will I fuckin learn that
a) customers lie
b) customers are sloppy
c) customers are wrong
d) customers do not do their work (properly)
e) customers want us to do their (dirty) work
f) possibly all of the freakinly above?! + khm....
They will fuckin aaaalwaaaays say sth is not working after the update..
And I will alwaaaays assume I fucked up something..even if I didn't touch that part of the code/data..
And almost aaaaalways it turns out that the bug they complain about is how the system worked (or didn't work) before the update and/or some fuckup from their side..
Anyhow, I rushed over, grabbed the files went testing in dev..wtf, output is different, mine is ok, theirs is..wtf is that shit?!
Transfer newly built dll to test..same shit as on prod..wtf?! How?!
I assumed they have thing A correctly linked to thing B.. ofc thing A was linked to thing C in their case and in another case (our test) to correct thing B..
I got chillies when grabbing files, that
I should have tripple checked that they didn't fuck up something on the link part, but I just assumed they know what they were doing & that they checked they linked correct files with correct content already, before being pissy that the update fucked up things.. riiiight!! :/
I wanted to find solutions to this fuckup asap so I disregarded my gut feeling..yet again!! Fuuuck!
I've spent too much time trying to find ways to fix a bug that wasn't even a real bug to begin with.. :/
Fuuuuuck!!
So yeah, always treat the customers like they are 3yrs old & have no clue what they are doing & check exactly wtf they were indeed trying to do..it will save you time & nerves..
And note to self: reread this shit daily!! And imprint it in your brain that everything is not always your fault!!10 -
My lessons both come from my current side project (I will share it with you in a week or two, the website isn't finished yet):
1. Every project comes to the point where it hurts to continue. Keep pushing, the result is worth it.
2. You aren't as good as you thought you were when you started, but you'll be better than you ever were when you finish.
3. Sometimes, there's more points to a list than you'd expect.
4. One hour per day is easier than five hours a week.
How?
Well. I started out my project knowing some C#, but Jack shit about unity. I know most of what I might build will end up being shit I'm gonna regret, refactor and recycle later. But I don't give a fuck. Doing it is better than planning it.
It sometimes hurts to get rid of a carefully planned algorithm that took hours to build because it fails in practice. But it's the right thing to do.
Never plan too much. If I'd have planned this project out, I wouldn't even have started with what I'm good at: write code, break shit and experiment.
It's easier to progress slowly but steady. Look at some awesome games that have been worked on for ages while the public had their say (RimWorld, Project Zomboid, Dwarf Fortress...) as opposed to those that are developed behind closed doors and rushed to the market before Christmas or some other major event (Mafia 3, Fallout 76, Fallout 4 VR...). Progress slowly, deploy early, push often. And the one hour per day approach is a good way to do this. -
Working on my personal projects really shows me how rushed the work is were I work, and it drives me crazy.
I know my code works 100% in my current project as it is unit and e2e tested, so I can edit it until the cows come home.. at work though, different story. -
One of our projects migrated their file-repository to another one during a major release.
Instead of giving this task to an experienced programmer, they gave it to the head of the respective dev department due to the usual release panic.
Soo.... He wrote the migration tool. It was executed during the release. Everything seemed fine so far.
A few days later. Someone from the above project came to my team due to some "strange behaviour on the production database".
They reported that they couldn't download some of the user's documents due to unknown reasons.
After quickly analyzing the current state of the new file-repository, we concluded that the affected documents did not exist in the new repository.
Then we took a look at the so called migration tool...
Well.. After nearly 30 min. we knew the root cause for that.
They only migrated the first 4 levels of the folder structure. Due to the assumption that "we don't use deeper nesting". (Facepalm)
As the head of their department wrote it, no one seems to questioned it either. Nor did they made a code review and ended up with a tool with hard coded urls to the production db, no version control, no build tool, no ci, nothing. Breaking nearly every possible company standard.
However.. That's not it. When analyzing their migration tool we noticed another even more dangerous thing.
They mixed up the id generation of the migrated documents resulting in a random assignment between customers and documents. Which is quite bad as this contains sensitive information. E.g. passports
They offered us quite a nice amount of money to fix this until EOB. We declinded as it was simply not possible in that time, but agreed to support them with the new tool.
After some time I heard that they migrated production again. And they fucked it up again. They never talked to us after we offered them support...
The third and final migration was written by us. Not only migrated it correctly. It was also way faster. By factor 20.
In the end we haven't gained anything from this rushed project as the penalties were piling up due to this fucked up migration.
After all this time I'm not sure who is to blame. In my opinion, partly all of them.
Head of department who can't and shouldn't code.
Seniors who didn't review the code and didn't ask for help.
Release mgmt who put way too much pressure on the devs. -
I feel like a lot of us write code without thinking it through beforehand. I spend more than half my day working everything out via diagrams on paper or lucidchart or with a coworker/previous maintainer (if applicable) before line #1 of code is written. Ideas are to code as source code is to build products - the latter is made (essentially by rote) from the former.
I'm glad I work from home thanks to 'rona, but before that, gah. Everyone else was visibly grinding away, and here I am staring into space thinking about the problem/project I'm working on. I'm not gonna sit there all day debugging code I once rushed. There's a reason the sites I maintain stay up and untouched by hackers (I think, you can never be sure...).3 -
So I was trying to root my Xperia Z2, starting by unlocking the bootloader. I rushed through the confirmation boxes to get the code, I entered it on fastboot... And realized I haven't made a backup. Phone restored to factory state. At least I had saved my photos on the SD card, but all the files, settings, configs and apps were gone along with my IM conversation database that I hadn't backed up for a month.
And I still haven't finished rooting that device.1 -
One day a week should be for improving the quality of the code, not just bugfixing and rushed implementation of new features.
-
Joined a new startup as a remote dev, feeling a bit micromanaged. So this week I joined an established startup as a senior mobile dev where I work remotely.
Previous two devs got fired and two new guys got hired (me as a senior dev and another senior dev as a teamlead, also third senior dev will join next week).
Situation is that codebase is really crappy (they invested 4 years developing the android app which hasn't even been released yet). It seems that previous devs were piggybacking on old architecture and didn't bother to update anything, looking at their GIT output I could tell that they were working at 20-30% capacity and just accepting each other MR's usually with no comments meaning no actual code reviews. So codebase already is outdated and has lots of technical debt. Anyways, I like the challenges so a crappy codebase is not really a problem.
Problem is that management seems to be shitting bricks now and because they got burned by devs who treated this as a freelance gig (Im talking taking 8-10 weeks pto in a given year, lots of questionable sick leaves and skipping half of the meetings) now after management fired them it seems that they are changing their strategy into micro managament and want to roll this app out into production in the next 3 months or so lol. I started seeing redflags, for example:
1. Saw VP's slack announcement where he is urging devs to push code everyday. I'm a senior dev and I push code only when I'm ready and I have at least a proof of concept that's working. Not a big fan of pushing draft work daily that is in in progress and have to deal with nitpicky comments on stuff that is not ready yet. This was never a problem in 4-5 other jobs I worked in over the years.
2. Senior dev who's assigned as the teamlead on my team has been working for 1 month and I can already see that he hates the codebase, doesn't plan on coding too much himself and seems like he plans on just sitting in meetings and micromanaging me and other dev who will join soon. For example everyday he is asking me on how I am doing and I have to report this to him + in a separate daily meeting with him and product. Feels weird.
3. Same senior dev/teamlead had a child born yesterday. While his wife was in hospital the guy rushed home to join all work meetings and to work on the project. Even today he seems to be working. That screams to me like a major redflag, how will he be able to balance his teamlead position and his family life? Why management didn't tell him to just take a few days off? He told me himself he is a senior dev who helped other devs out, but never was in an actual lead position. I'm starting to doubt if he will be able to handle this properly and set proper boundaries so that management wouldn't impact mental health.
Right now this is only my 1st week. They didn't even have a proper backend documentation. Not a problem. I installed their iOS app which is released and intercepted the traffic so I know how backend works so I can implement it in android app now.
My point is that I'm not a child who needs hand holding. I already took on 2 tickets and gonna push an MR with fixes. This is my first week guys. In more corporate companies people sit 2 months just reading documentation and are not expected to be useful for first few months. All I want is for management to fuckoff and let me do my thing. I already join daily standup, respond to my teamlead daily and I ping people if I need something. I take on responsibility and I deliver.
How to handle this situation? I think maybe I came off as too humble in the interview or something, but basically I feel like I'm being treated like a junior or something. I think I need to deliver a few times and establish some firm boundaries here.
In all workplaces where I worked I was trusted and given freedom. I feel like if they continue treating me like a junior/mid workhorse who needs to be micromanaged I will just start interviewing for other places soon.5 -
On a three months project for a website, the "strategists" and project managers spent two months and a half discussing the "strategy". It left us (production team) two weeks to create the content, the design, and code everything.
Of course it ended being rushed and somehow shitty, but they still congratulte themselves because they "nailed" the "strategy".
</rant>1 -
We are all about structures, clean code and many other things that make our life easier, right?
Well... It's not all white and black...
As talked many times, projects can be rushed... Client budgets can be low at the start and only then grow...
Let me take an example:
Client X needs a tool that helps his team perform jobs faster. They have a $500 budget. So... Testing, clean architecture and so on - are not really a viable option. Instead, you just make it work and perform that task as needed. So the code has minimal patterns, minimal code structure, a lot of repetitive parts and so on.
Now... Imagine that 3 months pass by without any notice and clients are ultra happy with the product. They want more things to be automated. They contact developers and ask for more things. This time they have a bigger budget but short timeframe.
So once again, you ignore all tests, structure and just make it work. No matter what. The client is happy again.
A year passes and the client realizes that their workflow changed. The app needs total refactoring. The previous developer has no time for adjustments at this point and hires a new company. They look at the code and rants spill out of their mouth along with suicidal thoughts.
So... What would you do? Would you rant about "messy project" or just fix it? Especially since people now have a bigger budget and timeframe to adapt to changes.
Would you be pissed on such a project?
Would you flame on previous devs?
Would you blame anyone for the mess?
Or would you simply get in and get the job done since the client has a "prototype" and needs a better version of it?
---
Personally, I've been in this situation A LOT. And I'm both, the old and new dev. I've built tons of crappy software to make things work for clients and after years - they come back for changes/new things. You just swallow the pill and do what is needed. Why? Well, because it's an internal system and not used by anyone outside their office. Even if it's used outside the office - prototyping is the key. They didn't know if the idea would work or be helpful in any way. Now they know and want it done correctly.6 -
I was thinking about the problems one of our clients faced with the launch of their project the other day, because things were rushed, stuff was omitted and in the end they could not meet the launch date, and I started making a list of hard lessons I learned over the years that would have helped them avoid this situation.
Feel free to add yours in the comments.
- Never deploy on Friday
- Never make infrastructure changes right before a launch
- Always have backups. Always!
- Version control is never optional
- A missed deadline is better than a failed launch
- If everything is urgent, nothing is important
- Fast and cheap, cheap and quality, quality and fast. Only one pair at a time can be achieved
- Never rush the start or the end of a project
- Stability is always better that speed
- Make technical decisions based on the needs of the project two years from now
- Code like you will be the only maintainor of the project two years from now. You probably will...
- Always test before you deploy
- You can never have too many backups (see above)
- Code without documentation is a tool without instructions
- Free or famous does not necessarily mean useful or good
- If you need multiple sentences to explain a method, you should probably refactor
- If your logic is checked beforehand, writing the code becomes way easier
- Never assume you understand a request the first time around. Always follow up and confirm
There are many more that should be on this list, but this is what came to mind now.2 -
probably when 8 hours before rushed release i pushed my part of the codebase into the wrong branch which fucked up everyone else's rushed release of different parts of that codebase and now a colleague had to spend several hours unfucking the repo on top of finishing the rushed release of his part of the codebase.
oh and in the end my code didn't even work as it was supposed to.7 -
Man, I enjoy the work I do and my boss is a great guy, but being rushed is never fun. And it's hard to say "it'll be done soon" if there's still some major features missing and the implementation is still unclear.
Can't a junior just take his time to make some decent code that won't end as spaghetti? I have enough PTSD of the first project I did here, which I still have to bugfix at least once a month 😂 -
For fuck's sake Microsoft, why on Earth do you announce a half-done feature? Was this an idea from marketing? Upper management? I am fairly certain that nobody who actually writes code for a living would have ever approved releasing a rushed feature to a TYPE SYSTEM.
7 -
Spent most of this week busting my ass working on a hotfix that came out of nowhere with mega high priority. This annoys me greatly because the hotfix wasn't even fixing a bug, it was adding new functionality because certain customers were being blocked from testing without this specific feature. In my humble opinion, given that we release every weekend, hotfixes should be reserved for actual critical bugs. But anyway, as I probably could have predicted, the code got to QA and exploded. Literally nothing works.
This is what happens when you try to rush out features to satisfy customers. If you try to rush something that is late, you WILL make it later.
Meanwhile there's an issue I'm supposed to be fixing for our next release which goes out this weekend and I've had no time to even look because of this hotfix. And now it's the end of the day and I just feel worn out from stress, tomorrow will no doubt be similar.1 -
Was rushed to write a crappy massmailing for super urgent newsletter, had to be finished in 20 minutes. Last 5 minutes i had to rewrite half of it. Told them its rushed, testet and crappy.
Mailed the stuff anyway. Every Email got the same dynamic string in subject.
Looked at code, was setting the subject 2 lines above the loop.
Sorry guys, dont rush me next time2 -
That moment when you have issue reports from clients about someone else half complete rushed code that got through yet someone else review... I'm not gonna fix that myself...
-
>start new job, not very professionally experienced dev
>spend couple of months working on a feature that is supposed to be an MVP kind of thing, be rushed to finish and told to cut corners because it's "just an MVP", still lose sleep and have relationship suffer (and ultimately ruined) as I try to not lose deadlines created by the boss with questions like "you can have this done by <very soon>, right?"
>frontend created by fellow developer is a garbled mess of repeated code and questionably implemented subpages, frontend dev apparently copies CSS from Figma and pastes it into new non-reusable React components as envisioned by designer, I am tasked with making sense of the mess and adding in API consumption, when questioning boss what to do with the mess I am often told to discard stuff that the frontend dev has made and just reuse his styling; all of this on top of implementing the backend feature that a previous developer wasn't able to do
>specs change along the way, I had been using a library as a helper in some part of the original feature, now the boss sees that and (without further testing the library) promises CEO that we'll add that as a separate subfeature, but the performance of the library is garbage for larger inputs and causes problems, is basically shit that might not have been shit if we had implemented it ourselves, however at this point CEO has promised new feature to some customers, all the actual sense of responsibility falls upon my hands
>marketing folk see halfway done application and ask for more changes
>everything is rushed to launch, plenty of things aren't implemented or are done halfway
>while I'm waiting for boss to deploy, I'm called up to company office by CEO, and get new task that is pretty cool and will actually involve assessing various algorithms and experiment with them, rather than just stitching API calls and endpoints together, it involves delving into a whole new field of CS that I never had the opportunity to delve into before
>start working on cool task, doing research, making good progress
>boss finally deploys feature I had been originally implementing
>cut corners of original boring insane feature start showing up, now I have to start fixing them instead of working on cool task, however the cool task also has a deadline which is likely expected to be met
I'm not sure if I'm having it bad or not, is this what a whole career in software development will look like?6 -
Do you want to know why all the popular open source projects have less-than-optimal, sometimes really dirty code?
It's because their developers ditched all the unnecessary stuff to just get the damn thing done. When I choose an open source dependency, I don't need unfinished stuff. I need a stuff that works and has all the features I need from the very start. If it works, I don't care about code quality in my deps.
This is the reason why dirty, rushed stuff with a great idea behind it gains popularity. PHP, Git, jQuery, the list is quite large.
While you've been busy polishing your files hierarchy, these guys already shipped their product, gained adoption, and their userbase doesn't need your product anymore.
This is applicable only for true open source, not "it's developed by a full-time team of principal developers and the CTO is fucking Kent Beck, it costs $1m per month but yea we have it on github".3 -
So I got rushed to finish the transposition of an already existing big feature (rushed like before the end of the week)
and now I got scolded because I HAD to do copy/paste some code not to lose time (and also because I wasn't explained how the code works, and I have no time to understand it). While I was waiting for answers for, like, a whole month and a half
Me in my mind : (╯°Д°）╯︵/(.□ . \) -
Fixing some terrible rushed code from a group assignment last minute. what could've taken hours to compute, finished in under a second afterwards.
-
2 weeks+ ago I made a PR into our codebase containing sample refactor that streamlined a significant portion of code. Also, I did refactor only on two handler packages (for MVC folks, that's Controller) as proof of concept, to figure out how convinient / logical the part would be for everyone.
We have rule of 2 approvals for merge (for 5 team members)
While writing refactor, it obviously blown up a lot of unit tests, but still coverage was fairly poor (that stuff was rushed, there was back than no time for unit tests). After my refactor I spent couple of days writing tests that hit fairly sweet (comparatively) coverage. (I managed to bump coverage from low 20s to high 80s, and have less code for tests)
I got first approve pretty much immidietely, other team member was on vacations, and 2 of them forgot.
We generally try to close PRs fairly quickly (usually same day kind of deal), but that one was just.. hanging in there. So I pinged everyone to re-check it to greenlight it but of course, loo and behold, merge conflicts arised. I ended up fixing actual logic (just some method signatures changed, not a big deal) and ran the units.
So, one of that handlers got quite a few of edits, and guess who is pretty much rewriting unit tests for second time now...
Dude, sometimes I question why tf I even bother with these tests... Feels like sabotaging my productivity, especially with bullshit like that3
Top Tags
Weekly Rant
View