They’re easier to spell than foldiers

I will offer my users a "File Lake" and count on AI/ML to deliver to them what they need at least 30% of the time. Users can create their own GUI in my "Visual Folderless" 5GL drag-and-drop editor. That way each user has a perfectly customized experience for their needs.

But no tags. Tags are a crutch. AI is the answer.

Also blockchain. Very very blockchain.

FWIW we have a services based set of architectures and we use tooling (again, our own) to maintain hierarchy. There are loooots of repos in our bitbucket, but a small number of "master" repos that give high level information about clusters and services. Our tooling uses these master repos to manager provisioning, but there are also user-level tools that allow you to manage the repositories locally in a more sane manner. For example you can ask to have all the repos (or a subset) cloned into a hierarchical set of directories, with the toplevel being "projects" with projects containing clusters and clusters containing repos.

You can check them out flat if you want too and it's not too bad, because the tooling generates repo names for you, so your repos end up named $project-$cluster-$service (so do your builds, and the builds are also automatically managed hierarchically)

I just want folders. We spent 2 hours in a meeting today trying to decide on repo-naming conventions because github has no folders. WAHHHHHHH

Well this has been a fun quarter so far...

This senior engineer who joined has been so stubborn. Him and the other staff engineer have been back and forth disagreements on the design of our features. My manager asked me to join in on the design meeting today and after walking in the room (I got pulled in 10 mins into it), I could feel the tension in the air. At the very end of the meeting, my manager asked the senior engineer if we could have a grooming session where we estimate the approach that the staff engineer suggested, and he straight up said "No, I just won't have time for that and refuse to do that".

He is flat out refusing to work with our staff engineer since he disagrees with the design. There are tradeoffs with both approaches so to me either one works, but I just find it odd that he is so stubborn that he is willing to die on this hill.

While me and the new grad want to take this project under our own hands and run with it. Currently it feels like this project is walking through mud with the staff and senior engineer constantly bickering each other.

Is Staff or Senior more "senior" at your shop?

Staff is more senior. The positions are

Software Engineer 1 (new grad)
Software Engineer 2
Senior Software Engineer
Staff Software Engineer

Which design is better?

Yeah can you describe the approaches?

Let's be honest, you would have just spent 2 hours arguing about folder structure and naming conventions instead.

But it's much easier to change folders later - unless they're in the URL to the repo, then that could cause problems.

Being able to painlessly re-organize your components into folders, rename, break into subfolders, etc. - is a highly underrated design feature imo. I always try to design a way to do that for the parts of my app/system that I know are going to grow and evolve over time.

Despite lying about it repeatedly in interviews I have never had a major disagreement about software approaches.. hasn't all that stuff been hashed out, can't you google things and more or less do the industry standard nowadays?

Industry standard usually only gets you so far. You still have to answer a lot of questions specific to your app/organization/workflow imo.

Also it's fun when you strictly adhere to industry standard and 2 years later the big players are putting out talks about how bad that approach is. Prime example: half my books seem to think an API Gateway is some kind of an anti-pattern. While the other half think it's great: https://medium.com/paypal-engineerin...y-2c18849ab3e2



Lol dude - orchestration isn't cool. It's all about choreography now.

I just read a bunch of microservices books and other than "Keep microservices small and don't share a DB" - I couldn't tell you what industry standard is. Even less so with Lambda - which makes it a lot more fun to develop in.

The current industry standard for node seems to be an awful typescript-express app with one layer for back end services and at least one for route-handling - in a many to many relationship. And maybe a models directory thrown in to gunk things up and make it even more like a Spring app or something. Bleh.

I much prefer a flat component-based structure where pretty much all the business logic is in one route-handler - and just use low-level supporting libs. No models and definitely no stickiness with the front end.

Correction: the awful typescript thing might not exactly be an industry standard. But if you're a Java dev looking to get started, it's probably the one that will appeal to you. Which is another potential downfall in that deciding what is and is not the "industry standard" could leave room for a lot of implicit bias.

Relevant:

I don't even understand how that would be possible.

A small start-up should behave very differently than a high-growth pre-IPO company should probably behave differently than a massive multi-decade conglomerate.

A healthcare company should behave very differently than a mass-consumer gaming company should behave differently than NASA.

Maybe I'm misunderstanding your question.

The staff soft engineer design is more future proof since he is treating the new domain model as something separate. The argument that the other guy makes is that they are very similar to the current model in behavior so we should just add an enum to specify the new type otherwise we would be duplicating something that is very similar.

I think the Staff?s approach is more correct and is similar to how we treat it in our business domain. However my only concern is that we tend to try to future proof things with no use case in the near future. I can see the seniors perspective that it will take time and he wants to keep things simple.

After reading what I just wrote I come to realize that the senior engineer has a common theme of trying to avoid doing work that would require investment in learning something new. In a meeting yesterday, we were discussing a bug in our software that require some diving into how our ETL works and he was adamant about himself not investigating on how to do that since he ?lacked experience? with that. It?s a reoccurring thing that he does, where he doesn?t like to spend effort on trying to learn something new and he brings on a whiny attitude about it.

Wow I just realize I hate this guy.

He seems to lack ambition as well as street smarts. Probably not a good career move to just flat refuse to do something that a higher level person wants done without extremely concrete reasons, especially if you aren't a superstar on the fast track.

They're having an argument about whether to add an enum to a data model? Holy ****.

This is probably my UI role shining through, all I'm saying is when we have a "bigger" thing to do I'll talk it through with my team and we'll just do it the way it probably should be done without someone saying "oh no we should do it Foo way" and someone else adamant about about doing it Bar way. Never had those kinds of arguments.

You are fortunate or very, very feared in your organization.

What is your guys thoughts on really short interviews? Most in my past exp are like 30-60min.
I spent several days preparing for a react/front-end interview, then the interview lasted 20~ minutes, it was a mix of behaviour/tech.
The only tech questions were "What IDE do you use" and "Do you know typescript"?

Am I drawing dead or what?

Do not work there

Also, man, 30-60 minute interviews? All the interviews I've been on in the last 10 years have been 6-8 hours.

Both bolded things are bad imo. One is bad design, the other is a bad developer tendency - crustiness. The older you get the more you have to consciously push back against it IME.

The tech place I interviewed for a long time ago was like 20 minutes aside from small talk and it was because no one at the company (in that area) (including me to start) knew what they were doing. I impressed them with something trivial that they didn't know how to do. (javascript calculator) (I also had friends who worked in other departments who recommended me and they were very well respected in the company)

But....working for people who don't know is pretty cool if they just defer to you on things you know better, which they did. It was a great job.

Yeah - this is basically the guy everyone is afraid of hiring when you show up to job interviews as a "grey beard". I realized a little too late that a majority of my efforts should have gone towards demonstrating to them that I wasn't that guy.