Yeah, payroll was outsourced and they met with the firm once or twice a year. The firm took care of mostly everything legal, including insurances and tax benefits afaik. The head of “HR” was a lifelong friend of the owner so I guess he didn’t want to go there.

My experience in a big software company was different and probably just like yours. The people there were rockstars.

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.

I really like ReactiveX for async programming, though having to go through a library is definitely a pain. It also does not make it less awkward to design your public API unless you’re okay exposing Rx types. Fair points!

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.

The database should be made in Flash.

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.

Oh, very interesting! I bookmarked it thanks for sharing!

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”.