5 ms·

I can sympathize but it seems hard to argue with this developer's approach then. If it met the needs of the company, particularly to the desired level at the ti

I can sympathize but it seems hard to argue with this developer's approach then. If it met the needs of the company, particularly to the desired level at the times these features were requested, I don't think there's a valid critique of the developer's architecture beyond iT's NoT DoNe CoRrEcTlY. And still, there's a lot to be said for keeping your developer's entertained so they stick around.

airstrike 6y ago
> there's a lot to be said for keeping your developer's entertained so they stick around Really? At the expense of everyone else who has to deal with this monstrosity for the foreseeable future, or worse yet replace it with an actual tool that can be reliably used. This JSON-inside-sqlite-inside-JSON-inside-a-JSON-string beast should never have seen the light of day. You're not paid to be entertained, sorry. You're paid to be productive. As productive as you can, and to put the needs of the client and the long-term success of the company hopefully first but certainly before any resemblance of entertainment if you're getting paid Did I mention you're getting paid to work?
tegiddrone 6y ago
On the other hand, other sorts of devs would probably not be entertained having to maintain a in-house database some unchained dev decided to introduce into the stack one day for "reasons." That tech debt will compound until it becomes more of a liability.. hopefully the product brings in enough money so that the in-house database can continue to be supported or removed. This sort of stuff is what deters me from being a developer sometimes. Fuck the salary, get me out of here.
bvinc 6y ago
I can certainly say that that's exactly the way I felt complaining about it. I felt like I was an asshole attacking him, and I don't think he liked me very much because of it. The whole thing was very uncomfortable. I didn't throw a fit. I tried to be very understanding and make suggestions. If it's any consolation, it fell on to me to maintain this code after he moved on to something else, which is why I know so much about how it works.
- airstrike 6y ago
  > If it's any consolation, it fell on to me to maintain this code That's not any consolation... If anything, it's all the more reason for you to be pissed off. He should have dropped the project, rolled out a future-proof tool and taught to do differently next time. Anything short of that is just enabling the dude's delusion of grandeur and therefore a mistake on everyone else's part...
- david422 6y ago
  > it fell on to me to maintain this code after he moved on to something else This has happened to be before. I disagreed with a technical direction, it was implemented anyways, and then I'm left to maintain it. Very frustrating.
- musingsole 6y ago
  If you're maintaining it, then I think you get a fair vote in it's architecture going forward. Things that are plainly problematic now didn't seem that way to a different group of people in a different context before it was even created. Perhaps it was a cascade of poor choices, but regardless, identifying problems with the architecture in the context of today gives a huge advantage over those who were putting it together under who knows what conditions (at work or elsewhere). Just like the never ending "turn this Excel workbook into an app" stream of work, refactoring older apps will be a constant. Focusing today's conversations on yesterday's mistakes only detracts from the work left to do (which is to say if your architecture change arguments are valid, there should be ways to justify implementing them today outside of "it should've been done this way in the first place because then we wouldn't have had those problems that are now solved anyway")
- deleted 6y ago
  [deleted]
- honkycat 6y ago
  You are never an asshole for telling the truth. I've dealt with this before, it is a form of gas-lighting. Some people are good at making everyone else into a bully when THEY are the actual bully. Like the kid who keeps splashing you in a pool, but runs off and cries and tells when you splash them back. Standing up for yourself sometimes makes you look/feel like an asshole. That doesn't mean you are wrong or that you shouldn't do it. edit: Check out the book "Radical Candor" if you regularly struggle with expressing negative feedback
mkhalil 6y ago
I left my last company because one of my co-devs would always do crazy hack-job things, and when I complained to them or higher-ups, the excuse was: < "Well all the work was already developed, and it would take too much time to rewrite it. You should have said something earlier" > "When?" I asked, considering she had just put up the (big) PR's and PR's ARE the time to review... < "Check her commits as she pushes them to the repo" - as in her bugfix/feature branches, not master... My jaw dropped. Especially since I was hired on as "Lead" and had all the accountability but no actual power.
- jack_h 6y ago
  Yeah, I'm in a similar situation at the moment. It's incredibly frustrating because during code reviews I will request changes so it's not such a broken hack job, and the response will basically be "No, it's not worth changing". At which point I'm the one "holding up development". We wasted hundreds of development hours during the last project because of this persons "inventive" code, and nobody seems to understand what's going on. Shame the job market is a bit crap right now.
  - munk-a 6y ago
    It's hard to get more strength to push back with out of thin air. I'd encourage you to try pushing for more detailed post-mortems (if you don't already have them) and just keep an eye out on how much curtailed reviews cost the company. You also really want an advocate for code maintenance and if you don't have one of these with a loud voice there isn't a really feasible way to solve it except becoming it yourself and earning the trust of those above you. Two pieces of actual useful advice I can offer are: 1. A review style I picked up based off of RFC 2119[1] basically the reviewing software we use allows us to mark particular comments as blocking of non-blocking and I pair that with the usage of MAY/SHOULD/MUST within the comment language i.e. "We're using the old `array()` syntax here instead of `[]` we MAY wish to use the more modern syntax" this allows me some room to elevate necessary change while keeping in the nitpicks I really want to throw in (and I do try and minimize them) without lowering the power of the strong comments. I've used MUST maybe three times always for something incredibly terrible like pages not loading or migrations to the DB that are unsafe and cause data loss. 2. Agree on syntax and style rules and enforce them. It's easier to get people to agree to rules once than try and argue for them on each PR - anything like brace placement or line limit shouldn't come up repeatedly since it wastes everyone time and makes folks feel belittled. 1. https://www.ietf.org/rfc/rfc2119.txt https://www.ietf.org/rfc/rfc2119.txt
jjeaff 6y ago
I disagree. It's coder malpractice. There is something to be said for a quick solution that just gets the job done. But each one of the updates described would take more work than just implementing SQLite or similar. Sure, on the outset, do something quick and dirty. By the second or third iteration, any legitimate developer should have switched to a database solution. Creating technical debt for no reason or invalid reasons is just a good way to setup your company for failure.
kbenson 6y ago
> If it met the needs of the company, particularly to the desired level at the times these features were requested, I don't think there's a valid critique of the developer's architecture beyond iT's NoT DoNe CoRrEcTlY. I'm pretty sure the cascading series of "his next problem" sentences implies that there were plenty of problems with the architecture that weren't identified ahead of time, and they had to encounter and then fix as a series of bugs. > And still, there's a lot to be said for keeping your developer's entertained so they stick around. There's a difference between keeping your developers entertained and letting them infect production with ill-conceived projects that cause problems for all those that interact with them. This project is reimplmenting something already solved multiple times. There are many document stores, and JSON interfaces and addon to traditional RDBMS, so what was being solved here, other than letting someone scratch an itch at the expense of the division he's working in. You're better off giving him 20% time for his own projects and calling it a day if you really think entertaining your developers is important enough to warrant it. There are times when rolling your own is useful. Generally when there's some extreme requirements for space or performance, but even that becomes rare when the area is mature and explored thoroughly. A database, even a JSON document store of some sort, is so mature that to make it worth while for one person to roll their own when it seems to need all the common features (locking, remote access, different clients), that to actually recoup the cost of building our own (much less the future cost of troubleshooting and bug fixing) is almost impossible unless you're somehow hired a genius workaholic for peanuts.
- dnautics 6y ago
  I would say operator friendliness is actually the best reason to roll your own (was clearly not the case here). If you have a system that is less complex, because it meets your use case only and not the competing use cases of every damn engineering outfit that can pay overpaid and underqualified devs to commit to an open sourced codebase, and as a result requires less labor to manage (for example, not using kubernetes for a 3 person startup), you should roll your own.
  - kbenson 6y ago
    Sure, but there are different levels of "roll your own". Mysql or Pestresql + a text field and a microservice front end for access control and JSON validation (if you don't want to use the included components from those respective projects that handle those for you) is easier and friendlier most of the time than a microservice on top of sqlite on a local disk, which is friendlier than replacing sqlite with BDB, which is probably friendlier than rolling your own storage format. Once you've abstacted it to a service, your API is what you and your client (should) care about, and many of the arguments for more specialized implementations no longer apply. Personally, I think the only reason I would go with something like sqlite instead of Postgres/Mysql behind a microservice is if I was baking the date into it with each release, so the sqlite data files are shipped with the version released. Even then, I'm not sure there's any reason I would do anything other than sqlite though. Even if I had need of lots of JSON files, I would probably have my build procedure process them into an sqlite file I tested and shipped with, if only because I would then avoid having to deal with all the problems this guy encountered by trying to make his own database.

airstrike 6y ago

> there's a lot to be said for keeping your developer's entertained so they stick around Really? At the expense of everyone else who has to deal with this monstrosity for the foreseeable future, or worse yet replace it with an actual tool that can be reliably used. This JSON-inside-sqlite-inside-JSON-inside-a-JSON-string beast should never have seen the light of day. You're not paid to be entertained, sorry. You're paid to be productive. As productive as you can, and to put the needs of the client and the long-term success of the company hopefully first but certainly before any resemblance of entertainment if you're getting paid Did I mention you're getting paid to work?

tegiddrone 6y ago

On the other hand, other sorts of devs would probably not be entertained having to maintain a in-house database some unchained dev decided to introduce into the stack one day for "reasons." That tech debt will compound until it becomes more of a liability.. hopefully the product brings in enough money so that the in-house database can continue to be supported or removed. This sort of stuff is what deters me from being a developer sometimes. Fuck the salary, get me out of here.

bvinc 6y ago

I can certainly say that that's exactly the way I felt complaining about it. I felt like I was an asshole attacking him, and I don't think he liked me very much because of it. The whole thing was very uncomfortable. I didn't throw a fit. I tried to be very understanding and make suggestions. If it's any consolation, it fell on to me to maintain this code after he moved on to something else, which is why I know so much about how it works.

airstrike 6y ago
> If it's any consolation, it fell on to me to maintain this code That's not any consolation... If anything, it's all the more reason for you to be pissed off. He should have dropped the project, rolled out a future-proof tool and taught to do differently next time. Anything short of that is just enabling the dude's delusion of grandeur and therefore a mistake on everyone else's part...
david422 6y ago
> it fell on to me to maintain this code after he moved on to something else This has happened to be before. I disagreed with a technical direction, it was implemented anyways, and then I'm left to maintain it. Very frustrating.
musingsole 6y ago
If you're maintaining it, then I think you get a fair vote in it's architecture going forward. Things that are plainly problematic now didn't seem that way to a different group of people in a different context before it was even created. Perhaps it was a cascade of poor choices, but regardless, identifying problems with the architecture in the context of today gives a huge advantage over those who were putting it together under who knows what conditions (at work or elsewhere). Just like the never ending "turn this Excel workbook into an app" stream of work, refactoring older apps will be a constant. Focusing today's conversations on yesterday's mistakes only detracts from the work left to do (which is to say if your architecture change arguments are valid, there should be ways to justify implementing them today outside of "it should've been done this way in the first place because then we wouldn't have had those problems that are now solved anyway")
deleted 6y ago
[deleted]
honkycat 6y ago
You are never an asshole for telling the truth. I've dealt with this before, it is a form of gas-lighting. Some people are good at making everyone else into a bully when THEY are the actual bully. Like the kid who keeps splashing you in a pool, but runs off and cries and tells when you splash them back. Standing up for yourself sometimes makes you look/feel like an asshole. That doesn't mean you are wrong or that you shouldn't do it. edit: Check out the book "Radical Candor" if you regularly struggle with expressing negative feedback

mkhalil 6y ago

I left my last company because one of my co-devs would always do crazy hack-job things, and when I complained to them or higher-ups, the excuse was: < "Well all the work was already developed, and it would take too much time to rewrite it. You should have said something earlier" > "When?" I asked, considering she had just put up the (big) PR's and PR's ARE the time to review... < "Check her commits as she pushes them to the repo" - as in her bugfix/feature branches, not master... My jaw dropped. Especially since I was hired on as "Lead" and had all the accountability but no actual power.

jack_h 6y ago
Yeah, I'm in a similar situation at the moment. It's incredibly frustrating because during code reviews I will request changes so it's not such a broken hack job, and the response will basically be "No, it's not worth changing". At which point I'm the one "holding up development". We wasted hundreds of development hours during the last project because of this persons "inventive" code, and nobody seems to understand what's going on. Shame the job market is a bit crap right now.
- munk-a 6y ago
  It's hard to get more strength to push back with out of thin air. I'd encourage you to try pushing for more detailed post-mortems (if you don't already have them) and just keep an eye out on how much curtailed reviews cost the company. You also really want an advocate for code maintenance and if you don't have one of these with a loud voice there isn't a really feasible way to solve it except becoming it yourself and earning the trust of those above you. Two pieces of actual useful advice I can offer are: 1. A review style I picked up based off of RFC 2119[1] basically the reviewing software we use allows us to mark particular comments as blocking of non-blocking and I pair that with the usage of MAY/SHOULD/MUST within the comment language i.e. "We're using the old `array()` syntax here instead of `[]` we MAY wish to use the more modern syntax" this allows me some room to elevate necessary change while keeping in the nitpicks I really want to throw in (and I do try and minimize them) without lowering the power of the strong comments. I've used MUST maybe three times always for something incredibly terrible like pages not loading or migrations to the DB that are unsafe and cause data loss. 2. Agree on syntax and style rules and enforce them. It's easier to get people to agree to rules once than try and argue for them on each PR - anything like brace placement or line limit shouldn't come up repeatedly since it wastes everyone time and makes folks feel belittled. 1. https://www.ietf.org/rfc/rfc2119.txt https://www.ietf.org/rfc/rfc2119.txt

jjeaff 6y ago

I disagree. It's coder malpractice. There is something to be said for a quick solution that just gets the job done. But each one of the updates described would take more work than just implementing SQLite or similar. Sure, on the outset, do something quick and dirty. By the second or third iteration, any legitimate developer should have switched to a database solution. Creating technical debt for no reason or invalid reasons is just a good way to setup your company for failure.

kbenson 6y ago

> If it met the needs of the company, particularly to the desired level at the times these features were requested, I don't think there's a valid critique of the developer's architecture beyond iT's NoT DoNe CoRrEcTlY. I'm pretty sure the cascading series of "his next problem" sentences implies that there were plenty of problems with the architecture that weren't identified ahead of time, and they had to encounter and then fix as a series of bugs. > And still, there's a lot to be said for keeping your developer's entertained so they stick around. There's a difference between keeping your developers entertained and letting them infect production with ill-conceived projects that cause problems for all those that interact with them. This project is reimplmenting something already solved multiple times. There are many document stores, and JSON interfaces and addon to traditional RDBMS, so what was being solved here, other than letting someone scratch an itch at the expense of the division he's working in. You're better off giving him 20% time for his own projects and calling it a day if you really think entertaining your developers is important enough to warrant it. There are times when rolling your own is useful. Generally when there's some extreme requirements for space or performance, but even that becomes rare when the area is mature and explored thoroughly. A database, even a JSON document store of some sort, is so mature that to make it worth while for one person to roll their own when it seems to need all the common features (locking, remote access, different clients), that to actually recoup the cost of building our own (much less the future cost of troubleshooting and bug fixing) is almost impossible unless you're somehow hired a genius workaholic for peanuts.

dnautics 6y ago
I would say operator friendliness is actually the best reason to roll your own (was clearly not the case here). If you have a system that is less complex, because it meets your use case only and not the competing use cases of every damn engineering outfit that can pay overpaid and underqualified devs to commit to an open sourced codebase, and as a result requires less labor to manage (for example, not using kubernetes for a 3 person startup), you should roll your own.
- kbenson 6y ago
  Sure, but there are different levels of "roll your own". Mysql or Pestresql + a text field and a microservice front end for access control and JSON validation (if you don't want to use the included components from those respective projects that handle those for you) is easier and friendlier most of the time than a microservice on top of sqlite on a local disk, which is friendlier than replacing sqlite with BDB, which is probably friendlier than rolling your own storage format. Once you've abstacted it to a service, your API is what you and your client (should) care about, and many of the arguments for more specialized implementations no longer apply. Personally, I think the only reason I would go with something like sqlite instead of Postgres/Mysql behind a microservice is if I was baking the date into it with each release, so the sqlite data files are shipped with the version released. Even then, I'm not sure there's any reason I would do anything other than sqlite though. Even if I had need of lots of JSON files, I would probably have my build procedure process them into an sqlite file I tested and shipped with, if only because I would then avoid having to deal with all the problems this guy encountered by trying to make his own database.