I agree with you in the sense that I only want to work places that recognize and value great code.
But everywhere has code that stinks. And it's hard to find people with the skills and experience to get rid if it. Before it can be gotten rid off, it must be understood.
In a sense it might be valuable to use the poor code in a reading screen. Firstly so we can agree it stinks, and the reasons why. And secondly, to find people with the attitude required to clean up messes that they didn't create (good scouts).
Even when the job is greenfield, or extending great code, I'd rather have engineers with the battle scars of doing tough maintenance.
The management has to be set up to allow for this. People have to be able to work towards something as a team; else we are all cleaning in different directions.
I see a few people didn't like what you said, and that's mystifying to me because while I understand the point of view of the business owner, as well as the reality that nearly all code stinks more or less, at the end of the day your #1 obligation is to your own interests. There's no reason people should choose to work on projects they don't like if they have no financial need to do so, or if the pay isn't enticing enough.
Attitudes will change in the next decade when vulnerabilities in software and tech become more obvious, serious, and regulated. Right now we're all happy hogs feeding from the trough of few meaningful standards, but the time will come when we are blamed for human lives lost as a result of bad code, and it's no longer going to be funny that we get paid so much to write such shit. As well, doing whatever companies pay us to do will become more shameful. From much of what I read here on HN and what I've seen in my own experience, way too many software developers will do practically anything for money and prestige.
This is why the selfishness of only wanting to work with teams that write decent code is actually more beneficial for society than "fail fast, bruh". Already, the tech bruhs aren't revered so much as they were even a handful of years ago.
We need an oath the same way doctors do. We also need Software Craftsmanship principles. Unfortunately industry sucked in too many coding monkeys to make such drastic move with good pacing. Like you said - ppl have to die or be annoyed a lot to start regulating IT hard.
But TBH mission critical software has completely different set of checkboxes that are not so easy to fulfill.
I switched from dropbox to mega years ago when the former removed Linux support. TIL mega have version support so I need to enable that and try it out.
First thing I do on a new device is setup my mega shared drives - and there is a lot of plaintext files there!
Dropbox never removed linux-support at all, or sync specifically. They removed support for some esoteric filesystems which lacked certain features. For most people dropbox on linux did not stopped working.
As a small dev team we have a workflow to rapidly author tests integrating our internal and external graphql + rest APIs.
These tests can be run, tweaked and parameterized in various environments from the GUI, and then imported into our CI system with Newman. Its a low code approach that's saving us time so I'm grateful of the features we are getting (for free) with Postman.
That sounds really neat is it some thing you can share? I recently setup a new machine which didn't take very long, but I have run into a few things I forget so would like to set up something similar.
I basically just run an install script which does a few different things. I start by updating the repos and regenerating my mirrors so I get the fastest downloads possible. After that, I install shell utilities (my editor, shell of choice, base-devel, etc.) and then I enable the AUR so I can grab the rest of my desired apps. The rest of it is decidedly basic, it just copies my tracked config files to ~/.config/ and moves my wallpaper to /usr/share/wallpapers. I run a few rain dances automatically too, like `sudo chmod a+wr /opt/spotify` (which lets me automate my Spotify theming process) and installing/unzipping a Steam theme.
To install, I run `git clone https:github.com/username/repo && ./repo/install.sh`, and I'm off to the races. I really reccommend writing one for yourself, as it's a great way to learn shell scripts.
For me there's a trade-off, depending on how often I setup a new machine. Value of automating with a procedural script vs taking the opportunity to try a leaner (or more modern) toolchain.
Currently upgrade about every 2-3 years, so I do tend not to need a bunch of things each iteration, and might upgrade OS. But I'd like a backup in case e.g. hardware failure, laptop lost or stolen.
Some declarative workstation config like terraform or Ansible would be interesting.
Thank you! I agree with so much in this, it really strikes the right balance of clean code vs productivity.
One of my peeves is a review that points out a bug/incorrectness without offering proof, or suggesting the fix/correct way. The reviewer might observe a code smell, but it's so much better dealt with a question-comment, e.g. "did you try?" vs "this looks wrong".
I generally aim to make every comment a question ("can we..."), and not make assumptions that the author didn't think of something already. Unless I just stating an objective fact that is clearly unknown e.g. "this duplicates library function x...".
Yeah the general style of putting comments into questions is much better.
But that's not exactly what I meant with question-comments, I sometimes genuinely don't know why are they doing something like this, or have to ask for additional testing/evaluation/analysis/profiling results before I can decide that it's most likely not going to blow anything up. And as long as there's low probability of damage (or rather low expected value of damage) I am happy with the change :)
What really helps is a style guide. It shuts most of those pointless style nitpicks, God I hate them.
I was surprised there was no mention of whitelisting.
If I know the queries that client apps are going to be running it would be useful to lock the API down to those. It sacrifices flexibility, but if you control apps and server, e.g. a startup then you still get the benefit of flexibility in development. Just need a system of add to the whitelist before deployment.
I have been looking for a way to achieve this with graphene but looks like there isn't a library for that yet. I'm wonder if other platforms offer this?
I've been wanting this for years and have been tempted to write it myself.
I've imagined a way to create your graphql query in a UI then "bookmark" it.
After that you'd grant permissions to use that bookmark via some authentication system. Possibly via a security team or API team to review the implications of the query. Security, performance, etc.
So you get fast and flexible development but you have a minimal surface area when refactoring, auditing security, and monitoring potential performance issues.
One other thing that's useful is for reaching out to the appropriate team to discuss deprecation, security concerns, and new upcoming features.
The team that needs to improve the database (in some way) can quickly figure out who to talk to instead of needing to ask multiple teams "hey, we're thinking about X, does that affect you?" The other teams are often busy and it takes time to analyze their code to figure out if it would affect them. It can be a miserable and slow process. With a bookmark, it's obvious and straightforward.
If anyone is familiar with something along these lines I'd love to hear about it.
The proposed solution does exactly what you describe in the first part. By turning GraphQL Operations into an RPC endpoint, we've essentially whitelisted the Operation. We've not only whitelisted the Operation but added a whole lot more but obviously I don't want to repeat the article. If you're interested discussing this further, find my contact information at the end of the blogpost.
This very good practice and I am pleased that the one time I got the dreaded message from GitHub and AWS, that I'd done the unthinkable (on a public repo), the keys were only for accessing a single junk dev S3 bucket - phew!
But no amount of layering makes the problem go away. Sometimes god-like keys are unavoidable. Those needed by Terraform etc are an example that comes to mind.
But everywhere has code that stinks. And it's hard to find people with the skills and experience to get rid if it. Before it can be gotten rid off, it must be understood.
In a sense it might be valuable to use the poor code in a reading screen. Firstly so we can agree it stinks, and the reasons why. And secondly, to find people with the attitude required to clean up messes that they didn't create (good scouts).
Even when the job is greenfield, or extending great code, I'd rather have engineers with the battle scars of doing tough maintenance.