• 0 Posts
  • 19 Comments
Joined 11 months ago
cake
Cake day: August 3rd, 2023

help-circle


  • Yeah, 4 employees out of 20.

    The fact this department even existed is a mystery to me. They didn’t even screen candidates or participate in interviews. It was basically 4 glorified secretaries. To be fair they also managed the payrolls, which consisted of sending the same excel file to he accountant each week. Realistically we would only have needed 1 person to keep track of whatever might pop up and to make sure the payroll system was up to date. The owners liked to screen and do the interviews themselves.

    At some other place I worked we had 1 admin/accountant person working like 1 or 2 days a week for a business of about 40 employees. Again the owners were taking care of new hires.

    HR as a department seems largely useless unless you’re hiring 365 days a year and have so many employees that you can’t keep up with all the requests. HR people are usually terrible at screening candidates anyway.


  • Holy. One place I worked at had way too many HR personnel. It was crazy. I happenned to have my workstation directly next to them. They quite literally did nothing all day. Nothing. At. All. It blew my mind.

    So why did we have so many? Well at basically every company-wide meeting this dep was putting on the biggest theater performance of being overwhelmed by “governmental endless bureaucracy” or something. So they always tried to hire more of their own friends. Temporary roles always became permanent and we ended up with 20% of the company working HR. The owner of the company, bless his heart, really could not say no.

    My experience with HR in most companies has been hit and miss, but this one example really opened my eyes. Of course if you hire people who are basically actors you run the risk of forming an HR dep that is very dramatic and manipulative.

    I can’t really blame the workers for taking advantage of an easy job and making a great living out of browsing Facebook and gossiping all day. But it really suck that the actual good workers were over-worked because other areas of the business were under-staffed. Virtually nobody else had the political impact in the hiring process HR had. Obviously this business wasn’t run by genius.



  • It is incredible really, I worked with C# for so long, and I tend to be very critical of the stuff I’ve used for a long time. For C#, I am struggling to figure how I would improve it, because all the stuff that suck in C# is usually the lesser of two evils.

    Of course if you hate classes, types, managed memory or anything invented in the last 20 years you will hate it, and I’ve met people like this. That is why you gotta keep learning as a dev, you don’t want to be one of those.



  • Yes, and the test suites were insane. The program was outputting a lot of data, and we basically asserted on anything and everything for any given integration. I mentioned that testing wasn’t the only issue, well there was a lot of issues. Unfortunately the behaviour changes were requested by the stakeholders and there was no way around it. That being said, had this thing we maintained been properly developed those changes would have been a breeze imo. The actual requirements were very simple.

    But anyway, I realize this is maybe an extreme example to paint integration tests negatively, but the point remain. In this scenario, every time we changed a bit of code it broke dozens of integration tests instead of breaking just a relevant integration test, had everything that could have been unit tested been written that way. The integration tests could probably also had been less… exhaustive, but it was probably for the best considering the codebase.


  • Makes a lot of sense. I figure contract tests is more or less what I have been doing then.

    I think there is that misconception that unit tests are about validating each line of code and preventing logic bugs. Though obviously you understand that this isn’t just about that, or not at all about that I would argue. Unit tests won’t prevent accidental breaking changes, but you can at least add new tests every time this happen, so you’re at least guaranteed that the next maintainer won’t be doing the same mistake.

    In an ideal world we could probably have nothing but integration tests, but in my experience if you only do integration testing you end up working really hard maintaining tests that are prone to break and costly to run. Unit tests are cheap to code and cheap to run, it is a great place to enforce your “contracts” with tests that are theoretically immutable. After those tests are out of the way, you can focus only on the actual interaction between your systems with the more expensive tests.

    Anyway, you have a good take I am just blabbering. This is based on my personal experience as someone who only cared integration tests but was later converted by a person much smarter than I am. And then later on by joining a team that exclusively did integration testing, hundred of tests. It was hell (imo), we had to change dozens of tests for every little bit of modification. The rest of the team seemed fine with it though. We rarely shipped bugs but progress was incredibly slow for a module of such low complexity. Testing wasn’t the only issue with that codebase though.



  • It seems to be a rare talent indeed.

    I am a programmer so my own approach is to find whatever similar project had to solve the same UUx requirements, either by searching the web or from memory, and to start iterating on that. Fortunately it is pretty uncommon to have to reinvent the wheel.

    Well, most of the UX designer I have worked with don’t do that, and most didn’t seem to have that much experience using softwares. I have seen some weird shit in meetings, as the “non-expert” it can be very delicate to call those bad designs repeatedly. Even basic rules like when to use radio buttons vs checkboxes are sometime broken. All people working 6 figure jobs++.

    I guess I have spent too much time on the computer over the last 2 decades and played around with too many interfaces to ever be satisfied with much of anything.


  • The best codebase I have ever seen and collaborated on was also boring as fuck.

    • Small, immutable modules.
    • Every new features was coded by extension (the ‘o’ in S.O.L.I.D)
    • All dependencies were resolved by injection.
    • All the application life cycle was managed by configurable scopes.
    • There was absolutely no boiler plate except for the initial injectors.
    • All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
    • “Refactoring” was as simple as changing a constructor or a configuration file.
    • All the input/output of the modules were configurable streams.

    There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you’re a newbie, but it was absolutely brain dead to maintain and extend on.

    Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I’ve seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we’d casually make the change while joking about it.

    It might sound mythical and bullshity, and it wasn’t perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.

    That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not “fun”, programming like a cowboy and ignoring the tests is a whole lot of fun.


  • I think unit testing is good at enforcing a spec so other developers know what to expect from your module and how to maintain it. It also kinda force you to dogfood your own stuff. I see a lot of hot takes about unit tests (its okay, this is why we’re here), but I am a bit curious how many people here worked in big chaotic software companies before and not just hobby project or small teams.

    Imo it is strictly something you do when you write something like a library or any sort of module that you expect other developers to interact with. I’ve seen teams get all smug about code coverage as if this made them diligent. My personal experience is that developers who understand why unit tests are important tend to write better code than those who skip them or do it “just because”.


  • After 10 years working in offices, the last 3 being mostly remote, I hate to say it because I am lazy and it makes no sense to commute 2hours a day to go into an overcrowded city, but being in a physical location beats remote if done right.

    The problem is, it is rarely done right. Some workplaces also just happen to be filled with people I will never bond with.

    I also fucking hate to have my calendar filled with meetings and useless 1:1. It is worst than it ever been. What could have been a quick chat at my desk is now a reserved 1h long meeting for which I have to prepare and stay glued at my webcam for.

    I have a friend who absolutely love remote and webcams. He loves sitting still in front of the computer and making faces and everything. Well I am not like that. I like multitasking, talking to people while I work or moving around. I loved going out for dinner with the people I bonded with to talk about stuff.

    Work in the office can be made to not feel like work, I experienced it in at least 1 place. Made me feel like I was hanging out with friends all day. Remote work will sort of always feel like work for me, even with the people I like it is sort of meh. Being on call is too intrusive and not being on call is too isolated. We’re sort of missing the in-between. Anyway I could go on.

    I always wished I could simply teleport into the building, because the commute has always been the worsy part of the day, by far.


  • You cannot do a whole lot without JS to be honest. My comment was not about Facebook but fingerprinting in general, though I kinda forgot to mention. I suspect finger-tracking strategies are kinda trade secrets so it probably varies. Running a VM still expose your VM settings, which basically let them track your VM around. This is the insidious thing about fingertracking, you can be followed around with spoofed data just as well. The very first time you will login anywhere, whether you use a VM or a VPM everything you touched with those settings will now track back to you.



  • To be honest, I had a similar experience in a workplace, and I definitely did not have the guts to post it before reading your comment.

    It is important to take all accusations seriously, but it is also important to verify.

    I have seen baseless accusations getting reported and shared on my previous workplace. It was made to sound like a living hell, and frankly you would have needed to be on a psychotic break to experience it like this. This same employee had pledged on their first day of work to print a chart of conduct and equality that would bind us all. It was very weird to be honest. Unfortunately some people saw the articles and believed every words and felt “betrayed” by my old bosses.

    Anyway, here’s a disclaimer because everytime I post an anecdote encouraging to be diligent I get replies telling me I am assuming this or that. Let me be clear, I believe Madisson and I would be very surprised if she wasn’t abused considering everything. But still, I like to verify, we must always verify. In this case, it means waiting for further development. You can encourage and support the supposed victim while simultaneously not jump to the throat of the accused.