Thanks, I edited to clear that up. Yes, I meant hiring his son. I think loliander was explicitly claiming that it impacts their honesty and credibility.
>I'm suggesting that this father may have engaged in nepotism once before, which makes me question his integrity.
It's absolutely a mistake and a lack of critical thinking to believe that any given father would go out of his way and put his own reputation at risk for his son. Some would. I don't know if it's even a majority. But plenty of fathers would not, even if they're present in their son's life.
It worked for me last year, and entertained a few of us for a good while. Been meaning to revisit.
Side note: Elite Dangerous is on offer at the moment and that has been the only thing to give me that unnerving sense of scale you get when travelling between systems.
I don't write a lot of while loops so this is just a bit unfamiliar to me, but I'm not really understanding how this isn't the same as `do{block}while(condition);`? Could you give a simple example of what kind of work `prepare` is doing?
Think of a producer (a method that returns data each time you request one, like reading a file line by line or extracting the top of a queue for example) that you need to parse and process until you find a special element that means "stop".
I'm aware this example can be trivially replaced with a while(data=parse(producer.get())){process(data)} but you are forced to have a method, and if you need both the raw and parsed data at the same time, either you mix them into a wrapper or you need to somehow transfer two variables at the same time from the parse>condition>process
A do-while here also has the same issue, but in this case after you check the condition you can't do any processing afterwards (unless you move the check and process into a single check_and_process method...which you can totally do but again the idea is to not require it)
Being only in my 30s but also affected by a lot of usually-age-related disability has been a big struggle for me as a programmer. I don't know how typical it actually is, but I guess I skipped the "work way too hard because your body can handle it" phase that appears to build reputation and wealth early in a career. Probably it would have been different if I'd grown up more physically active; I basically hate most sports and other ways of staying healthy and didn't learn their value until it started getting in the way of the things I do love.
Regardless, it's a massive toll on my mental health. Although frequently assured otherwise, I constantly feel like a burden on my team, like I'm unreliable, for being unable to put in the same hours my older coworkers do. As difficult as it is to start now, focusing on developing my physical health is the only way forward.
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.
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.
// 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.
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.
}
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:
but evidently it is not just that it is serialized multiple times, otherwise it shouldn't need the try catch (of course one problem with online discussion of code examples is you must always assume, contra obvious errors, that the code actually needs what it has)
Something upstream, sure, but often not something "fixable" either, given third parties and organizational headaches some places are prone to.
Yeah. I imagine that's a bandaid around having to consume a dodgy api that they didn't have access/permission to fix.
The blanket catch is odd though, as I'd have thought that it would still be outputting valid json (even if it has been serialized multiple times), and if you're getting invalid json you probably want to know about that.
I've seen this happen when someone's not familiar with their api framework and instead of returning an object for the framework to serialize, they serialize it on their own and return a string. Which then gets serialized again by the framework.
You came in so confident it was wrong, but it turns out you don’t really know what it does.
Please take a lesson from this. Good code is not the one that follows all the rules you read online. Your coworker you dismissed understood the problem.
I didn't know that JSON.stringify could be called multiple times on the same object and then unpacked via repeated calls to JSON.parse. So I was wrong on that. I think definitely this warrants a comment in the code, at the least explaining why this was taking place. The likely reason for the nesting was I think calling an LLM for a valid json object and somewhere in that workflow the json object was getting stringified more than once. I suspect this is the fault of the codebase and not the LLM itself, but it was typical of these devs to not ever investigate the api to understand what it was returning and rather just apply bandaid after bandaid.
I reserve my general opinion on the quality of this coder's work, as evidenced by the quality of the app itself among other things. But I guess you'd have to just trust (or not trust) me on that.
I think asking questions is ideal. Even when I'm 99% sure a line is blatantly wrong, I will ask something like, "What is this for?". Maybe I missed something - wouldn't be the first time.
>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.
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").
There are however some people who think they are sticky but aren’t really. Some but not all of them use Impostor Syndrome to keep their followers in line. You can recruit most easily from people they’ve left twisting in the wind when their suggestions and ideas turned out to not work, but only if you always deal with the poor consequences of your own decisions. People will follow ideas they don’t quite understand if they know they won’t be working alone at 7 pm on a Thursday fixing it.
These sort of people will vote for you publicly. However some lot them will still take the path of least resistance when you aren’t looking.
It was sort of a nasty surprise when I figured out one day that there are people in this industry that will agree with high minded sentiments in public but not lift a finger to get there. I ended up in a group that had two or three of them. And one day due to a requirements process fuckup we had a couple weeks with nothing to do. They just did the Hands Are Tied thing I’d been seeing for over a year (yes we should do X but we have to do Y for reasons) and I saw red. Luckily I was on a conference call instead of sitting in front of them at that moment. But I’m sure they heard the anger lines over the phone.
If the boss doesn’t give you an assignment, you work on tech debt they haven’t previously insisted that you work on. Simple as that. At most places if my boss disappeared, I could keep busy for at least three months without any direction. And keep several other people busy as well. If you don’t know what to work on then I don’t know what’s wrong with you.
You are most likely giving the only real answer. However I just say its better to not care. Look how much energy and mental strife you are going through to line someone else's pockets against their will. That only is not even including the actual work just the unnecessary work around the work. Its not worth it. If the tech is this dysfunctional then so is the rest of the organization, you breaking your back to fix one support structure is just masochism.
Heh, unfortunately it's been this way in almost every company I have been in.
I don't think that I have ever been in a company where I haven't had to deal with it - and it's taken me a while to work it out, I've had physical threats and (just this Christmas gone) been punched in the stomach at a work Christmas event by someone upset that I'm able to point out these other ways of doing things.
People are very scared of losing what little power they think that they have.
This exactly. I worked at a place one time with a terrible code base. They based it on open source and slapped on additions with no style or documentation.
My first day, I couldn't even stand the code base up on my local dev environment, because there were so many hard-coded paths throughout the application, it broke (they were unwilling to fix this or have me fix it).
I tried to accept their way of coding and be part of the team, but it got too much for me. They were staunch SVN supporters. This isn't much of a problem, but we had constant branching problems that Git would have resolved.
As I got assigned work, I noticed I would have to fix more bugs and bad coding, before I could even start the new addition/feature. It was riddled with completely obvious security vulnerabilities that were never fixed. Keep in mind that this was the new product of the entire company with paying customers and real data.
The team lead was also very insecure. I couldn't even nicely mention or suggest fixes in code that he had written. The interesting thing is that he didn't even really have a professional coding background. He went straight from tech support to this job.
I lasted about a year. I got let go due to 'money issues'. Shortly before this, they wanted me to merge my code into my branch with the Jr. developer's code right before my vacation (literally the day before).
I merged it and pushed it up to the repo (as instructed) and the team lead sent me nasty emails throughout my vacation about how various parts of my code 'didn't work'. Not only were these parts the Jrs code, it wasn't ready for production.
The other thing to know about the team lead is that he was extremely passive aggressive and would never give me important project details unless I asked (I'm not talking details, just high-level, what needs to be completed).
We had a call where he told me I 'wasn't a senior developer'. I wanted to tell him to fuck off, but I needed the job. The company went out of business 2 months later.
I found out their entire business model relied only on Facebook Ads, and they got banned for violating their rules.
Totally agreed - a correctly used password manager is many, many times easier and faster to use than so-called magic links. It's not even a contest.
I'd even say magic link emails border on misuse of email; they're a fundamentally different form of communication from all other uses of email. It's not easy on neurodivergent brains to deal with that combination of pollution (magic links in my inbox) and distraction (actual emails in my face when I'm trying to log in and was not trying to check my email). Protonmail's client could really make my day if they found a way to reliably separate those 2 channels so I didn't have to even open my inbox to get login codes/links.
What I don't understand is why I've never been prompted to use a password manager by any site with a signup flow. It seems easier to normalize their use through messaging than keep acting like passwords are supposed to be something you consciously remember. Nobody should remember their passwords, except for maybe 2-3. But now we're moving toward a world where login just means more friction and less control instead...
That is a very good point! You'd have to be careful to craft the messaging so that it doesn't imply you can help troubleshoot the password manager.
But something simple could work. Already you usually have a note under a password field, "Must contain at least 8 characters and at least one special character" or something to that effect. It could also have some note about "We suggest a randomly generated password from your password manager."
I'm not building this out so I don't need every hole poked in the idea, just seems like it could work.
If someone is going to do this, 'At least one special character' etc. is not the way to do it. According to OWASP guidelines, a secure password must enforce a minimum length but not any other specific criteria, because they actually end up reducing password strength. Instead, the best option is to add a password strength indicator below the password entry field, to encourage the user to create a strong password. The help text can also mention using a password manager but it's difficult to do in a good way.
One of my pet peeves is when rules counteract the purpose they are supposed to serve, usually because of incompetence. Two years ago, I worked for a few months for a company where time reporting was accessed through a specific web page.
They required the password to be changed monthly, have at least 10 characters, at least one number and at least one special character. On top of that – they locked out password managers and pasting. "We need to make sure you are the one logging in and not a hacker that hacked your password manager" they explained when I asked.
Out of spite I went for "Password12!" the first month and "Password123!" the month after, at which point I received an email from the IT department explaining to me that my choice of password was endangering the corporations security.
You can tell them to write their password on a piece of paper in their drawer. Seriously.
Many home users are pretty good about protecting important scraps of paper. The government gives us plenty to hold onto. Even if they’re a grandma that doesn’t understand all this password manager mumbo jumbo, they can deal with a notebook and be better off than using the same password on every site.