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
-
@2xCmet guy is a developer he ain't not got time for 2 rants a day XD
-
-
@practiseSafeHex
TRAG I think I know where you are heading too..
I am voting for G right now.. Seems the best contender so far.. E D or Y might also have a chance.. Cant say..
✌️ -
@dustybolt the api returning an error response is how it is done everywhere.. even for your own components, if there is something invalid, the entire application doesnt crash, never..
For an invalid login, you return the appropriate error message, not crash the app and dump a shitload of exception log stack trace.. -
@dustybolt so we couldn’t return an error to them. We we integrating with an existing system and the client were not changing it. We had to download data and use it, end of story. These were HUGE systems.
I wasn’t involved in the library project, had never built anything like that before. Not saying my solution was perfect, but it would have worked, not crash the app and we’d know about issues.
Main point of the story was, he intentionally crashed the whole app for something that should have been a silent library. Any errors or issues should have been handled in some way internally.
It was a few years ago now so I’m struggling to remember the exact details but I think the majority of issues came around because there were assumptions made about the responses. I think certain keys in the JSON were assumed because 1 other client had it in there’s. -
@dustybolt “not starting the app if missing confit is defendable”:
- yes if it controlled the entire app, because everything would be fucked. But should still throw an error message on screen and not just close.
- not in this case as it was solely for the analytics library. If the config was missing, the app would function 100% without any issues. User shouldn’t suffer because of that -
@g-m-f llllooooonnnnggggg complicated story, I'm pretty sure no, but was about too.
That company got a new CTO, he started firing a bunch of people he shouldn't have to cut costs, company kind turned against him and a bunch of us left.
Just before the mass exodus the CTO was fed up with G and putting him on projects where he could do no damage, but then we all left and I there wasn't many othesr around. Company pretty much collapsed after that -
@DucksCanCode well his name is G ... thought I made that pretty clear dude.
Address: no idea.
Darkest fear: code that compiles? closing a ticket? oh oh how about a coherent thought? ... yep thats the one -
At my company, I got asked: "What's the difference between an abstract class and an interface and why'd use them?"
At the moment, I thought of that question as ridiculous. When I was doing some interviews on the other side of the table, I was amazed.
And in your case, it would have saved quite a headache. And man-hours. -
i still don't use interfaces unless i am forced to use a pattern dictated by some client.I do full stack work - so do client side, middle ware and db all myself (including unit tests before passing it off to QA for further scrutiny).
I focus on only few things - promised functionality, ability to read and maintain the code..i factor in scalability based on the importance of the app. Most apps last at least 5-10 years which is pretty good considering the number of hours invested to dev and maintain.
Anyone think this is bad ? -
@bondman yup
-
@sSam please explain why ?
-
@bondman yup
-
@PonySlaystation please explain why ? How is it helpful if you are a full stack guy and your replacement is a full stack guy as well
-
@bondman I would not say your approach is bad in general.
Interfaces are really useful to define the data models which are shared between different services (e.g. client - server) and in other situations they are really useful as well if not important.
It depends on the application. -
@PonySlaystation I agree it has its place and use but 90% of the apps we build are like 20-30 screens on an average. This should be easily manageable by 1-2 resources if its even written by a beginner who has no clue about "best practices and patterns and all that stuff".
Good Morning!, its time for practiseSafeHex's most incompetent co-worker!
Todays contestant is a very special one.
*sitcom audience: WHY?*
Glad you asked, you see if you were to look at his linkedin profile, you would see a job title unlike any you've seen before.
*sitcom audience oooooooohhhhhh*
were not talking software developer, engineer, tech lead, designer, CTO, CEO or anything like that, No No our new entrant "G" surpasses all of those with the title ..... "Software extraordinaire".
*sitcom audience laughs hysterically*
I KNOW!, wtf does that even mean! as a previous dev-ranter pointed out does this mean he IS quality code? I'd say he's more like a trash can ... where his code belongs
*ba dum tsssss*
Ok ok, lets get on with the show, heres some reasons why "G" is on the show:
One of G's tasks was to build an analytics gathering library for iOS, similar to google analytics where you track pages and events (we couldn't use google's). G was SO good at this job he implemented 2 features we didn't even ask for:
- If the library was unable to load its config file (for any reason) it would throw an uncatchable system integrity error, crashing the app.
- If anything was passed into any of the functions that wasn't expected (null, empty array etc.) it would crash the app as it was "more efficient" to not do any sanity checks inside the library.
This caused a lot of issues as some of the data needed to come from the clients server. The day we launched the app, within the first 3 hours we had over 40k crash logs and a VERY angry client.
Now, what makes this story important is not the bugs themselves, come on how many times have we all done something stupid? No the issue here was G defended all of this as the right thing to do!
.. and no he wasn't stoned or drunk!
G claimed if he couldn't get the right settings / params he wouldn't be able to track the event and then our CEO wouldn't have our usage data. To which I replied:
"So your solution was to not give the client an app instead? ... which also doesn't give the CEO his data".
He got very angry and asked me "what would you do then?". I offered a solution something like why not have a default tag for "error" or "unknown" where if theres an issue, we send up whatever we have, plus the file name and store it somewhere else. I was told I was being ridiculous as it wasn't built to track anything like that and that would never work ... his solution? ... pull the library out of the app and forget it.
... once again giving everyone no data.
G later moved onto another cross-platform style project. Backend team were particularly unhappy as they got no spec of what needed to be done. All they knew was it was a single endpoint dealing with very complex model. There was no Java classes, super classes, abstract classes or even interfaces, just this huge chunk of mocked data. So myself and the lead sat down with him, and asked where the interfaces for the backend where, or designs / architecture for them etc.
His response, to this day frightens me ... not makes me angry, not bewilders me ... scares the living shit out of me that people like this exist in the world and have successful careers.
G: "hhhmmm, I know how to build an interface, but i've never understood them ... Like lets say I have an interface, what now? how does that help me in any way? I can't physically use it, does it not just use up time building it for no reason?"
us: "... ... how are the backend team suppose to understand the model, its types, integrate it into the other systems?"
G: "Can I not just tell them and they can write it down?"
**
I'll just pause here for a moment, as you'll likely need to read that again out of sheer disbelief
**
I've never seen someone die inside the way the lead did. He started a syllable and his face just dropped, eyes glazed over and he instantly lost all the will to live. He replied:
" wel ............... it doesn't matter ... its not important ... I have to go, good luck with the project"
*killed the screen share and left the room*
now I know you are all dying in suspense to know what happened to that project, I can drop the shocking bombshell that it was in fact cancelled. Thankfully only ~350 man hours were spent on it
... yep, not a typo.
G's crowning achievement however will go down in history. VERY long story short, backend got deployed to the server and EVERYTHING broke. Lead investigated, found mistakes and config issues on every second line, load balancer wasn't even starting up. When asked had this been tested before it was deployed:
G: "Yeah I tested it on my machine, it worked fine"
lead: "... and on the server?"
G: "no, my machine will do the same thing"
lead: "do you have a load balancer and multiple VM's?"
G: "no, but Java is Java"
... and with that its time to end todays episode. Will G be our most incompetent? ... maybe.
Tune in later for more practiceSafeHex's most incompetent co-worker!!!
rant
candidate 4
wk87