Ranter
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
Comments
-
Very rarely.
Working on new stuff (greenfield development) is generally considered rare enough to be a perk - have a look at job descriptions and they'll sometimes list it specifically. Maintaining crap that other people have started is a much harder and more valuable skill to acquire. -
vane110525y1. Adding new features.
2. Refactoring of old code.
3. Fixing bugs
4. Adding tests to prevent bugs from point 3
5. Adding new apps ( hardly ever )
- that’s the current state of my work -
donuts236725y@vane do you refactor other people's code? Or just your own?
The problem I potentially see if you only worked on shitty code and then are told to design a new app bc ur senior, you'd do the same thing... And it'd be shitty? Maybe just a bit less... -
@vane
In terms of what I like to do
1. Refactoring old code
2. Fixing bugs
3. Adding tests to prevent bugs
4. Adding new features
5. Adding New Apps (because that requires planning, and proper planning is exhausting).
Much easier just to fix other people's mistakes
1. pick up enough of the syntax to comprehend the code (1 day)
2. pick up just enough of the framework/tools to be effective (1 week)
3. find and fix the bug (depends on the bug)
4. drink vodka
5. forget both the framework/tool *and* the syntax.
Rinse and repeat. -
vane110525y@billgates mostly other people’s code. Well I had the same approach ( rewrite everything ) before.
I was always tired and hated myself when looking at code.
Now I just move parts around. Lots of work is to find patterns you can move without changing logic.
I always try to put my part as plug in/out component so I don’t bother. -
@vane
I wish one day to actually be competent enough to make my own software instead of just this endless cycle of learning and forgetting, like a drunk mechanic who keeps using and losing his tools.
I feel like an imposter. -
donuts236725y@Wisecrack I learn, save down the important stuff in a app or document, then forget.
Then when I need it again I just go "where did I put this... I remember doing something like this before... Aha!"
And then try to understand what exactly was it that I should remember back from it.
Usually still takes a day or two but better then starting over again... But not sure if anyone else reads it.. But they definitely never create any themselves... -
vane110525y@Wisecrack try remember by connecting knowledge to some events. Keeping pure knowledge is hard but if you remember how you gained it it’s easier.
Remember the dots not the facts. -
@vane
I don't retain anything, except prompted by circumstance.
I'm grate at learning by teaching apparently.
But you know what they say: those who can't do, teach! -
I might actually be a rare case, that's almost all I've been doing since I've been a developer. There's a few times where I'll need to switch to maintenance mode and refactor someone's code but most of my stuff is writing new apps, or apps that need rewritten. Right now my boss is pushing to make us a Microsoft shop, I've rewritten six apps in the past year that were previously in other languages. It's been kinda exhausting to be honest. I want something easy like refactoring, especially since VS 2019 came out with their sweet expanded toolset for refactoring compared to what we were using before. Likely in the end it depends on where your company is at in it's life cycle and what your shop is currently doing.
-
donuts236725y@vomitmachine I guess I'm similar... Most of the orients this year have been sorry if do it yourself... And figuring out what caused a production issue.
Easy part is: not my code -
@billgates If I'm picking up what you're saying, I think it's understandable to be disappointed to not be working on something new. However, refactoring abilities are something that can't really be ignored. It helps to tell yourself that you're excited to try out different techniques while refactoring, because it is technically still coding. Just splitting that code up into small bits and bobs.
-
vane110525y@Wisecrack well half of the things I remember I know only that I know where or when I found them and why not what they do. Like ask me why to do 1 thing I answer because there was article about it I was reading. I don’t know what was article about but I know why I was reading it.
I know the correct answer, or just know where the correct answer is written and I don’t remember why.
From interview perspective it’s sometimes awkward. I give correct answer but can’t tell why. -
donuts236725y@vomitmachine ah sorry, was typing while leaving work...
Refactoring is good and I do it on my own code but if I look at someone else's code usually it's redo this, why did you do this, this whole thing is inefficient...
Nowadays I get less of that because I work on my own projects but actually today looking into a PROD issues in a group project. Root cause seems to be someone wrote code that blocked the whole thread (JS Node) and also spikes the CPU...
The whole thing pretty much needs to be rewritten and I'm going to myself, can u ppl first just learn to understand the fcking language differences before u write code think about things beyond N=100.
Drifting off, but basically feels like a lot of devs don't think beyond the simplest examples. -
donuts236725y@vane me too though even in interviews I tend to be more like "in more experiences than most of your devs probably, but I can't prove it in words"
-
vane110525y@billgates yeah amount of knowledge is increasing but my mind is limited. I hope when I’m old I will be able to convince young fellows to follow my lead and not to make same mistakes. Maybe not from the first try but second or third they start to believe me not treat me like old weird prick.
-
@billgates Ah yes, the classic, I need this out the door and I don't care how it operates. It's possible it could have been a time constraint to cause the guy who wrote it to just push it out the door. Or it could be your case where they may have been illiterate in more than just node.js...
At work, how often do you create your own apps? As opposed to adding a new feature to an existing one?
I am thinking maybe the biggest difference between me and everyone else on my team is because I have a lot more experience creating my own apps.
So when I get a problem I tend to start by thinking how to create a new app for it, what would be the ideal way to solve the problem. And then if needed, figure out how to integrate it into an existing project.
Whereas everyone else thinks about how to solve a problem within the context (and constraints) of an existing app.
question