5 ms·

> If it's actually better, others will start following your lead. Not really my experience in teams that create inconsistent, undocumented codebases... but you

> If it's actually better, others will start following your lead. Not really my experience in teams that create inconsistent, undocumented codebases... but you might get 1 or 2 converts.

peterldowns 2y ago
It depends on the day but generally I believe that most engineers want to write good code, want to improve their own skills, and like learning and critiquing with other engineers. Sometimes a small catalyst is all it takes to dramatically improve things. Most of the times I've thought that individual contributors were the problem, the real issue was what the company's leaders were punishing/rewarding/demanding.
- darepublic 2y ago
  doing some recent contract work I discovered someone putting this into a PR (comments my own) ``` let susJsonString = '...' // we get this parseable json string from somwhere but of course it might not be parseable. so testing seems warranted... try { // lets bust out a while loop! while(typeof susJsonString === 'string') { susJsonString = JSON.parse(susJsonString) } } catch { susJsonString = {} } // also this was a typescript codebase but all the more reason to have a variable switch types! this dev undoubtedly puts typescript at the top of their resume ``` I suppose this works?! I haven't thought it through carefully, it's just deciding to put your shoes on backward, and open doors while standing on your head. But I decided to just keep out of it, not get involved in the politics. I guess this is what getting old is like seriously you just see younger people doing stuff that makes your jaw drop from the stupidity (or maybe its just me) but you can't say anything because reasons. Copilot, ai assisted coding only further muddies the waters imo.
  - liontwist 2y ago
    This is totally fine. If you're given shit data this seems like a reasonable way to try to parse it (I would personally bound the loop). Typescript is not going to make it better. The problem is whoever is producing the data.
    - bryanrasmussen 2y ago
      I think the complaint here is they have a string, which even has the word string in the variable name, and they turn it into an object at the end. Hence references to Typescript. I suppose what is wanted is something like let parsedJSON = {} try { parsedJSON = JSON.parse(susJsonString) } catch { //maybe register problem with parsing. }
      - accoil 2y ago
        That's quite different though. It looks to be dealing with the case that a serialised object gets serialiased multiple times before it reaches that point of code, so it needs to keep deserialising until it gets a real object. E.g: JSON.parse(JSON.parse("\"{foo: 1}\"")) I'd guess the problem is something upstream.
        darepublic 2y ago
        The code is either going to loop once and exit or loop forever no
        andrewf 2y ago
        Putting this in my web console: let susJsonString=JSON.stringify(JSON.stringify(JSON.stringify({foo:1}))) console.log("initial:", susJsonString); try { while(typeof susJsonString==='string') { susJsonString = JSON.parse(susJsonString); console.log("iteration:", typeof susJsonString, susJsonString); } } catch { susJsonString = {}; } I see: initial: "\"{\\\"foo\\\":1}\"" iteration: string "{\"foo\":1}" iteration: string {"foo":1} iteration: object {foo: 1} A comment explaining the sort of "sus" input it was designed to cope with may have been helpful.
        accoil 2y ago
        It will stop when it gets something that's not a string due to while(typeof susJsonString==='string') { susJsonString = JSON.parse(susJsonString); as it'll keep reassigning and parsing until gets a non string back (or alternatively error out if the string is not valid json)
- aleph_minus_one 2y ago
  > I believe that most engineers want to write good code But the opinion what makes code good differ a lot between software developers. This exactly leads to many of the inconsistencies in the code.
  - niels_bom 2y ago
    And that’s why you talk about it and agree on stuff. I call that being a professional.
- Tallain 2y ago
  Exactly this. I (relatively recently) joined a team with a handful of developers all sort of doing things their own way. No docs, no shared practices, just individuals doing their own thing. After reviewing the code, submitted PRs with fixes, putting together docs for best practices, the entire team shifted their stance and started working closer together in terms of dev practices, coding styles, etc. Not to say I got everyone to march to my drum -- the "best practices" was a shared effort. As you said, sometimes it just takes someone to call things out. We can do things better. Look at how things improve if you approach X problem in Y manner, or share Z code this way. Maybe the team was overwhelmed before and another voice is enough to tip the scales. If you don't try, you'll never know.
- watwut 2y ago
  Sure, but that does not imply they will follow whatever you found out to be the best for the piece of code you are working on right now.
LAC-Tech 2y ago
ahh, there's a lot of scenarios here. in my scenario, those people were gone.
citizenpaul 2y ago
>Not really my experience in teams that create inconsistent, undocumented codebases... but you might get 1 or 2 converts. This has also been my experience. Usually there is a "Top" sticky/unhelpful/reticent person. They are not really a director or exec but they often act like it and seem immune from any repercussions from the actual higher ups. This person tends to attract "followers" that know they will keep their jobs if they follow the sticky person for job security. There usually are a few up and coming people that want better that will kinda go along with you for their own skill building benefit but its all very shaky and you can't count on them supporting you if resistance happens. I've literally had the "I was here before you and will be after" speech from one of the "sticky's" before. All these HN how to do better write ups seem to universally ignore the issues of power and politics dynamics and give "in a vacuum" advice. Recognizing a rock and a hard place and saving your sanity by not caring is a perfectly rational decision.
- jimbokun 2y ago
  Well HN was created as a forum for discussing start up best practices, which is all about disrupting big companies weighed down by internal politics.
  - awesome_dude 2y ago
    The linked article is about dealing with legacy codebases with millions of lines of code. The response is accurate - anyone that's had to deal with a legacy code base has had to deal with the creators of said birds nest (who proudly strut around as though the trouble it causes to maintainability makes them "clever").
- peterldowns 2y ago
  I tried my best to offer a pragmatic recommendation for dealing with those sorts of people. I'd love to know what you would recommend instead?
  - awesome_dude 2y ago
    IME it's politics, so you need to find someone that the sticky person fears/respects, and get them onboard. The only other way I have succeeded is to appeal to the sticky person's ego, make them think that it's their idea. Note: I have also had to deal with Sticky person: Do it this way Me: But X Sticky Person: No, do it the way I have decreed [...] Three hours later (literally) Sticky Person: Do it X way

> If it's actually better, others will start following your lead. Not really my experience in teams that create inconsistent, undocumented codebases... but you might get 1 or 2 converts.

peterldowns 2y ago

It depends on the day but generally I believe that most engineers want to write good code, want to improve their own skills, and like learning and critiquing with other engineers. Sometimes a small catalyst is all it takes to dramatically improve things. Most of the times I've thought that individual contributors were the problem, the real issue was what the company's leaders were punishing/rewarding/demanding.

darepublic 2y ago
doing some recent contract work I discovered someone putting this into a PR (comments my own) ``` let susJsonString = '...' // we get this parseable json string from somwhere but of course it might not be parseable. so testing seems warranted... try { // lets bust out a while loop! while(typeof susJsonString === 'string') { susJsonString = JSON.parse(susJsonString) } } catch { susJsonString = {} } // also this was a typescript codebase but all the more reason to have a variable switch types! this dev undoubtedly puts typescript at the top of their resume ``` I suppose this works?! I haven't thought it through carefully, it's just deciding to put your shoes on backward, and open doors while standing on your head. But I decided to just keep out of it, not get involved in the politics. I guess this is what getting old is like seriously you just see younger people doing stuff that makes your jaw drop from the stupidity (or maybe its just me) but you can't say anything because reasons. Copilot, ai assisted coding only further muddies the waters imo.
- liontwist 2y ago
  This is totally fine. If you're given shit data this seems like a reasonable way to try to parse it (I would personally bound the loop). Typescript is not going to make it better. The problem is whoever is producing the data.
  - bryanrasmussen 2y ago
    I think the complaint here is they have a string, which even has the word string in the variable name, and they turn it into an object at the end. Hence references to Typescript. I suppose what is wanted is something like let parsedJSON = {} try { parsedJSON = JSON.parse(susJsonString) } catch { //maybe register problem with parsing. }
    - accoil 2y ago
      That's quite different though. It looks to be dealing with the case that a serialised object gets serialiased multiple times before it reaches that point of code, so it needs to keep deserialising until it gets a real object. E.g: JSON.parse(JSON.parse("\"{foo: 1}\"")) I'd guess the problem is something upstream.
      - darepublic 2y ago
        The code is either going to loop once and exit or loop forever no
        andrewf 2y ago
        Putting this in my web console: let susJsonString=JSON.stringify(JSON.stringify(JSON.stringify({foo:1}))) console.log("initial:", susJsonString); try { while(typeof susJsonString==='string') { susJsonString = JSON.parse(susJsonString); console.log("iteration:", typeof susJsonString, susJsonString); } } catch { susJsonString = {}; } I see: initial: "\"{\\\"foo\\\":1}\"" iteration: string "{\"foo\":1}" iteration: string {"foo":1} iteration: object {foo: 1} A comment explaining the sort of "sus" input it was designed to cope with may have been helpful.
        accoil 2y ago
        It will stop when it gets something that's not a string due to while(typeof susJsonString==='string') { susJsonString = JSON.parse(susJsonString); as it'll keep reassigning and parsing until gets a non string back (or alternatively error out if the string is not valid json)
aleph_minus_one 2y ago
> I believe that most engineers want to write good code But the opinion what makes code good differ a lot between software developers. This exactly leads to many of the inconsistencies in the code.
- niels_bom 2y ago
  And that’s why you talk about it and agree on stuff. I call that being a professional.
Tallain 2y ago
Exactly this. I (relatively recently) joined a team with a handful of developers all sort of doing things their own way. No docs, no shared practices, just individuals doing their own thing. After reviewing the code, submitted PRs with fixes, putting together docs for best practices, the entire team shifted their stance and started working closer together in terms of dev practices, coding styles, etc. Not to say I got everyone to march to my drum -- the "best practices" was a shared effort. As you said, sometimes it just takes someone to call things out. We can do things better. Look at how things improve if you approach X problem in Y manner, or share Z code this way. Maybe the team was overwhelmed before and another voice is enough to tip the scales. If you don't try, you'll never know.
watwut 2y ago
Sure, but that does not imply they will follow whatever you found out to be the best for the piece of code you are working on right now.

LAC-Tech 2y ago

ahh, there's a lot of scenarios here. in my scenario, those people were gone.

citizenpaul 2y ago

>Not really my experience in teams that create inconsistent, undocumented codebases... but you might get 1 or 2 converts. This has also been my experience. Usually there is a "Top" sticky/unhelpful/reticent person. They are not really a director or exec but they often act like it and seem immune from any repercussions from the actual higher ups. This person tends to attract "followers" that know they will keep their jobs if they follow the sticky person for job security. There usually are a few up and coming people that want better that will kinda go along with you for their own skill building benefit but its all very shaky and you can't count on them supporting you if resistance happens. I've literally had the "I was here before you and will be after" speech from one of the "sticky's" before. All these HN how to do better write ups seem to universally ignore the issues of power and politics dynamics and give "in a vacuum" advice. Recognizing a rock and a hard place and saving your sanity by not caring is a perfectly rational decision.

jimbokun 2y ago
Well HN was created as a forum for discussing start up best practices, which is all about disrupting big companies weighed down by internal politics.
- awesome_dude 2y ago
  The linked article is about dealing with legacy codebases with millions of lines of code. The response is accurate - anyone that's had to deal with a legacy code base has had to deal with the creators of said birds nest (who proudly strut around as though the trouble it causes to maintainability makes them "clever").
peterldowns 2y ago
I tried my best to offer a pragmatic recommendation for dealing with those sorts of people. I'd love to know what you would recommend instead?
- awesome_dude 2y ago
  IME it's politics, so you need to find someone that the sticky person fears/respects, and get them onboard. The only other way I have succeeded is to appeal to the sticky person's ego, make them think that it's their idea. Note: I have also had to deal with Sticky person: Do it this way Me: But X Sticky Person: No, do it the way I have decreed [...] Three hours later (literally) Sticky Person: Do it X way