211–220 of 239 posts
Honestly, the truly 'smart' programmer isn't someone who does or doesn't use a bunch of techniques or best practices, it's the one who can look at the situation and do what's right for that particular project/job. Most of the things in this post could be the right answer if the project is a weekend side project that's going to get a few hundred views a month, or a website for a small business. Bob's Restaurant doesn'…
I can't tell if this is an honest call to keep things simple, or if it's meant to ridicule that idea. Because I strongly, deeply agree with some of these points, and am absolutely horrified by some of the others.
Yeah, I really can't tell if it's satire. Especially things like this: > I’m not smart enough to figure out how to transform data between different layers of the system, so I just don’t. I use the same represetnation in the UI layer and the storage layer. OK, well then you might need to gather a little more work experience and meet the repercussions of decisions like this one. Or maybe the OP is a contractor and neve…
Earlier quoted context omitted.
Not if the public view on the data doesn't change. Just the storage. That's sorta the point. To not have to version if you just change the underlying storage model. For example let's say for whatever reason we were storing a duration as an int. But instead we decided to migrate it to start time and end time. Do we need to force that change on everyone downstream and add a new major version API? Or can we just compute…
I disagree completely. If the data structure needs to be changed it needs to be changed at the beginning of the system typically the front end. And downstream code needs to be fixed to accommodate that. Otherwise youve created 20 different state machines for each part of the system stacked on top of each each other each expecting a different data structure and returning a different data structure. So changing anythin…
At this point you may as well just use a object or dictionary. The type doesn't give you any idea about the actual shape of the data.
Most projects don't need Docker. I have built multiple billion-dollar-a-year company websites from scratch (no, I don't make a lot of money, just a dev) that get tens of thousands of users a day and we barely ever need more than one or two instances of anything, all of which the major cloud providers can scale out of the box with Azure App Service / Elastic Beanstalk / etc. Docker/K8S is pure hype and never fills the…
multiple billion per year with tens of thousands of users per day? Assuming conservatively that this is 1B/year and 100K users/day, that's still $273/user/day. What are you selling?
Inventory tracking and auditing for Fortune 500 companies in a SaaS before that.
Earlier quoted context omitted.
> I've worked in a number of projects where they decided to move to microservices for reasons they wish they had I've advised engineers to rewrite code before, mostly for resume building to help jumping ship to somewhere better. Basically, use the current job as a way to train on the stack the company you really want to work for is using. If a company doesn't have a stock-based comp and sticks to prevailing wages/CoL…
It's unprofessional to do this in conflict with your company's interests. Use your own hobby projects to learn instead of leaving a maintenance project for your coworkers. It also creates an invisible bias towards worse companies in your next position, because smart companies are wary about this kind of behavior, and will be savvy to filter out candidates that have displayed it.
Great work happens at the intersection of employee's and company's interests!
Why not simply align the two? Compare the Xerox Alto with the Macintosh...
Earlier quoted context omitted.
> It becomes more art than engineering or science. The opposite. > All that comes down to the large variety of training everyone in the field gets, from university to youtube tutorials. A big problem is that a lot of the youtube/bootcamp ecosystem focusses on "teaching what they do at the FAANG" to lure people into thinking they could get a job there by enrolling/buying whatever training they are selling. And then th…
>And then these people repeat what they have been told are "the best practices". And then they get jobs which serve to validate their learning paths (maybe not at FAANG), which gives them confidence about what they learned being the right way to do things. >Proper engineering degree teaches about gathering requirement and analyzing the problem space to understand what really needs to be done. Well sure, but a lot of…
A lot of non-lawyers can discuss law principles and explain laws pretty well; but someone who passed the bar I know for a fact are familiar with certain concepts.
Same for engineers.
Earlier quoted context omitted.
I disagree completely. If the data structure needs to be changed it needs to be changed at the beginning of the system typically the front end. And downstream code needs to be fixed to accommodate that. Otherwise youve created 20 different state machines for each part of the system stacked on top of each each other each expecting a different data structure and returning a different data structure. So changing anythin…
Am I understanding that you think that there should be just one data structure which is shared between all teams which is a superset of all fields that it could have and people just add data to those fields? So at any given point you don't even know what data is present or not present depending on which point in the pipeline it has passed or not? At this point you may as well just use a object or dictionary. The type…
> So at any given point you don't even know what data is present or not present depending on which point in the pipeline it has passed or not?
At least with a non mutating data structure with the public contract you can tell if it's passed through a part of the pipeline because a required field is blank or null.
With a mutating data structure that gets changed, say 20 different times throughout the system you have no idea if it's passed through some part of the pipeline or not.
Even better if somehow everything can interact via a centralized database where all state is stored even intermediate state. Its not just storage. It's also state management.
Earlier quoted context omitted.
Yeah, I really can't tell if it's satire. Especially things like this: > I’m not smart enough to figure out how to transform data between different layers of the system, so I just don’t. I use the same represetnation in the UI layer and the storage layer. OK, well then you might need to gather a little more work experience and meet the repercussions of decisions like this one. Or maybe the OP is a contractor and neve…
> contractor and never has to deal with the repercussions of their actions. This doesn't match my experience of contracting. Not caring about code quality and then leaving others holding the bag of sh*t is frequently what "ladder climbers" do, and those are, by definition, on payroll rather than contractors. For a contractor, there is no ladder to climb, but willingness to get one's hands dirty is definitely part of…
Also, remember another possible reasons why a company might hire a contractor: to have someone to blame for a project they know is failing.
One of my favorite things about contract work is that it's time-limited. This means that I can be 100% honest about bad dev processes, bad code, bad management, etc., because I won't have to worry about angry managers making my life miserable for any longer than the remainder of my contract period.
I can't count the number of times I've spoken up about something terrible, only to have the permanent devs privately tell me later "I'm so happy you said that. I've been wishing I could bring that up for years"
Earlier quoted context omitted.
> the point of using a different layout/structure for storage vs the UI layer? By way of example, I'll point to the classic example of a New User form UI: that UI will need 2 password inputs (one for the password, the other for the "confirm password") - but your User object/schema/DB-table won't have two separate string password fields - it'll have a single binary/byte[] salted-password-hash field, and you certainly…
> the other for the "confirm password" That always pisses me off. I can copy/paste the password from the first field into the second. Hell, I use a password manager; I pasted into the first field, so I paste into the second. It's just a check to make sure they match. But my passwords are complicated enough that I can't remember them long enough to type the characters in the first time; I literally have to copy/paste.…
It's annoying, but I understand why that's done, so I don't get too upset about it.
But making me type in my email address twice? Grrrr.
Earlier quoted context omitted.
I've worked in a number of projects where they decided to move to microservices for reasons they wish they had, while not fully understanding microservices or applying basic litmus tests to where to split off services. So we ended up with great puzzles like how to link an order service with an inventory service to check if there's enough inventory to fulfill an order, all through a central event bus. Then of course t…
Unfortunately it's not a popular belief anymore, but [asynchronous] central event bus is a terrible idea on it's own, and it goes against what [micro]services are about. If you want microservices to work you shouldn't have anything central in them, and you should avoid async as much as possible.
One-way async dataflows work much better. That way each microservice is up with all the (potentially delayed) data it needs to respond to requests.