Hey I'm Raaid. I'm a software engineer who is particularly experienced with data engineering + the backend but full-stack capable. I'm interested in making something that works, works well, is well documented, and helps the world. I'm not interested in pointlessly moving fast to try to make a quick buck. Super interested in anything that aims to address climate or socioeconomic issues.
Hey I'm Raaid. I'm a software engineer who is particularly experienced with data engineering + the backend but full-stack capable. I'm interested in making something that works, works well, is well documented, and helps the world. I'm not interested in pointlessly moving fast to try to make a quick buck. Super interested in anything that aims to address climate or socioeconomic issues.
A lot of skepticism and negativity here, with a focus on "open source means something to me, not the layman" as well as mentions of is that really helpful, is it auditable, etc. Valid concerns, but I guess my reaction is hopeful because hey there's at least one group of people who are trying to build something that is more transparent.
Maybe it's not perfect, but (at least to me) seems like a step in a good direction. Also for what it's worth the company making the tech has a product for auditing as well. Idk guess I'm feeling more optimistic this morning.
> Maybe it's not perfect, but (at least to me) seems like a step in a good direction.
Is it? Provided you have a working democratic state with checks and auditing, what is the problem that voting machines solve?
The level of guarantees that you have with a paper vote is hard to surpass and the inconvenience of paper vote is not that big considering how often voting occurs (even in the extreme case of Swiss style referendums).
>Provided you have a working democratic state with checks and auditing, what is the problem that voting machines solve?
It solves the problem of waiting days or weeks for a result. It solves the problem of multiple languages on a ballot. It solves the problem of visually-impaired voters accessing the voting machine, it solves the problem of incorrectly filled out voting sheets (hanging-chat).
Hell, that's just off the top of my head, and I'm sure others can contribute more.
Is a paper-vote a reference to literally marking a piece of paper, or a human counting said piece of paper? Sorry if that's a dumb question, just want to make sure I follow. It seems like this tech works with marking a piece of paper that is then read by a machine. I suppose if the paper is kept, perhaps it's nice from the point of view of the election-handling-folks to automate the counting process, but be able to audit the paper ballots?
Voting machines are always a bad idea. There are issues of trust and security that can never be solved. So trying to open-wash this dangerous way of voting is at best just as bad as closed machines and at worst an angle to make people think its a safe and good idea.
But it is a solved problem. You can use machines to mark paper ballots, and to quickly tabulate them. This is the best of all worlds: the results are auditable, the user can confirm their ballot was recorded properly, and the election officials can quickly count the ballots.
Why are they always a bad idea in your view? I'd imagine that they're quite nice from the point of view of those who run elections and actually have to count them. I'd love to hear your thoughts!
Yes and no. There is never a situation where electronic voting with no paper back up that must be stored and catalogued for a prescribed time via law is a good idea.
But a system that uses electronics to tabulate votes that can be verified via paper ballots that are stored long-term, securely? Why not?
Edit: Maybe I didn't describe this well. The person makes the vote on paper. The paper is counted by a machine (like the article is saying). The paper is stored securely and catalogued for later reference and audit. What is the problem there?
> But a system that uses electronics to tabulate votes that can be verified via paper ballots that are stored long-term, securely? Why not?
If the paper ballots as backup are manually created by the voter then while it’s still possible it’s much harder to fake the votes en masse but there’s more scope for human error (what if they vote in two different ways). If the paper backup is automatically generated then can they check it? If not then there’s little improvement over purely digital voting. If yes, do they actually check it? Many won’t bother and maybe there’s an exploit there. Then there’s the fact that this system would require regular auditing, and lawsuits and close contests will force a certain number of audits every election. No one can reliably predict which districts will require audits so presumably they’ll need to hire sufficient people to do a manual recount anyway which eliminates the labor cost advantage.
If by using electronic voting we are opening up new potential exploits, even with paper backups, and not really gaining much of an advantage why would we go to the expense and bother of implementing electronic voting?
Sorry, when I say backups, I mean paper voted created by the voter's own hand as the original vote, counted by machine, and held securely as a way to verify the vote if any of the candidates call the election into question.
There is no system in which electronically cast and electronically created backups are a good idea.
> Maybe it's not perfect, but (at least to me) seems like a step in a good direction.
It just add bigger SPOF. Compromise a single voting machine and you control hundred thousands of votes. Compromise one vote counter and you control thousands at most
There are literally no problems to solve in modern functioning democracies when it comes to votes, it's just some technocrat mentality that requires everything to be automated so it's faster/more efficient, etc.
So yeah you can make these things faster at the expense of basically everything else, including trust
Interesting okay. Is a combo of paper and automated counting not ideal then? To my mind automatic counting is probably great for the speed you mentioned, and I'm sure those who have to perform the counting/run the election like it, but then keeping paper to hand-count as a backup or to verify seems sensible too. Or is the very possibility of a compromise too bad to entertain?
Speed of counting is not a problem. Most countries in the world finish counting their election votes by the end of the second day after the election, with pure paper voting. The great thing about elections is that election officials can very easily scale with the number of votes, so there is no reason why you'd need automation here.
"Open source" voting machines is essentially like baby-proofing a machine-gun. All of the problems that electronic voting poses to true democracy are 100% still there, but it looks safer - which may, unfortunately, make it more attractive.
I'm putting open source in quotes, since only software can be open source, a voting machine is a piece of hardware that you do not own, so you have no idea what it software it is running.
Big +1 to “ Never give up on local testing”. The current code base I’m dealing with has many tests that require interaction with a dev environment on the cloud, and occasionally these tests fail due to a timeout or some other thing not related to actually testing the code (and instead reveals that I forgot to refresh my MFA).
Additionally the dependency thing can be huge; we ran into a weird bug for installing a particular dependency on our CI system so our test there keeps failing, but being able to run it locally let’s us know that the changes did not break our actual code tests.
Yeah, that advice was bad and looked like it was written by someone that's done too many deployments and not enough development.
He's certainly right that deployment validation is the best test at some level. But it completely leaves off the most important aspect. That deployment validation, and the mistakes that you inevitably find, should directly guide your test development to prevent regression.
If you do this, future component upgrades and deployments get easier. Its well worth the extra effort.
He's not discouraging automated testing; he's just saying that we should prefer integration tests (using services running locally) to unit tests of individual functions. Look up "testing trophy" for more about this philosophy.
Totally with you on the value of integration tests. I'm familiar with the trophy and the triangle, but he's saying this:
'..with unit tests notably coming in last place – i.e. “only if you have some time”.'
The "only if you have time" part is what I disagree with. If we're doing TDD then I don't see how you can avoid writing unit tests, or even deprioritize them.
> The "only if you have time" part is what I disagree with. If we're doing TDD then I don't see how you can avoid writing unit tests, or even deprioritize them.
Perhaps the author doesn't recommend TDD? They don't suggest anywhere that they do. It seems to me that the industry these days sees TDD as a tool for occasional use, not the dogma once proposed.
+1 unit tests are essential for software evolution like refactors, updating business logic, and updating dependencies. More generally, good testing requires a defense-in-depth strategy and unit testing, integration testing, and canary testing all have a role to play. All other things being equal, it's much better to catch a bug before you even push to the the source repo versus when it has one foot out the door to your customers.
Yeah as some of the responses to your reply said, agreed, and I've always found value in unit tests, and the "too many deployments and not enough development" comment from jsight rings loud in my head. Deploying to a real non-prod environment as a "test" can be fine for a team, but to do so while not testing for how you expect the code to behave... maybe that works for some folks and if you're moving super fast, but I wouldn't be super comfortable with it myself.
I totally disagree with the author on testing. Integration tests are more trouble than they are worth in my experience, and unit tests are really useful.
Most people building stuff quickly in serverless seem to eschew the concept of local entirely, and it's something I've recently started doing too. I make a code change locally and it gets picked up by the deployment of my stack associated with my feature branch the second I save the file.
It's an uncomfortable concept at first but I find it's helped me build things faster and has ultimately led to less rabbit hole chasing across multiple categories of issues.
thanks for saying that! people are pretty skeptical about localstack when they hear about it for the first time, and don't understand how we could ever emulate something remotely resembling AWS. tbh sometimes i'm baffled myself, it's pretty crazy what it can already do (i work there).
With AWS SAM you can invoke functions locally, run api gateway and use step functions. There's also a 3rd party project to run various AWS services locally, can't remember the project name.
There's also SAM sync that syncs changes you make quickly, so if you have your own dev copy in AWS you can quickly test changes.
There's also a fair amount of lambdas where you can just invoke the lambda handler yourself without anything special other than a compatible version of python/node/etc. Variations of things like:
For golang, but would work in any language. What's really worked is the idea that your main loads configuration and injects all of the configured interfaces into your handler.
You then can build all of the testing on mocks/stubs to test the behavior. If you access a database you access in through the interface which can mimic the appropriate behavior for your code in test vs production. If you need to you can do local integration testing of the db access layer.
Honestly, my answer is: don't use serverless, or at least have a non-serverless way of running your code locally, preferably outside of a container/VM. Otherwise you have no way of running or testing your code locally, much less attaching a debugger; IMHO this can slow down dev cycles so much that it cancels out the time saved by adopting a serverless architecture.
Serverless deployments aren't painfully slow like they are with Kubernetes or other container orchestration platforms. At least with AWS lambda you can change and deploy your code in <10 seconds and have it taking traffic (In an infinite number of "environments"). So developing locally is kind of pointless.
> Serverless deployments aren't painfully slow like they are with Kubernetes
What are you doing with your K8s cluster/containers that is making your deployments slow? My cluster at work pulls down containers faster than my local, and deployments are usually swapping within ~1 minute of being committed in git/the container build finishing…
Hah tried to post this and it didn't work, glad for the confirmation. Not sure if its the right place to look, but https://stackstatus.net/ is also not working for me.
I found the author to have cherry-picked and poorly-cited information earlier on in the book when talking about antidepressants, and then a complete lack of rigor when discussing the various lost connections. I think he has a point, but I just didn't find it very well done, and as another comment here has quoted:
> Other clinicians say, however, that the notion of depression being because of a simple chemical imbalance is outmoded anyway, and that antidepressants remain a useful option for patients alongside other approaches including talking therapies.
I listen to a lot of podcasts, and I think this is really really cool. Would certainly become a better and better experience (I think?) as more people leave comments on episodes.
I’m also late 20s, have enjoyed some startup chaos, and have come to similar points regarding contentment derived from relationships and coming to terms with my limits and finitude. I’ve thought “Am I giving up? Am I just doing the easy thing so I can live comfortably? At the cost of my dreams/ambitions/yearning?” Which seems like what your mentor has named “boring”. But I don’t think it’s quite that simple.
There is nothing wrong with finding a state of being that is comfortable for you right now. Maybe this is what you need, right now. There is nothing that says this is how it will be from now on. You might quit and start something in 5 years, you might not. You might enjoy side projects or other creative endeavors alongside your job.
What you probably don’t want to lose is that creativity, that excitement. Again, that doesn’t need to look like a successful startup. It could look like a fun side project, a community effort you’re involved in, whatever. The point is, and I think this is a big realization for me from the past year (but what do I know I’m not even 30) is that you don’t need to put all your eggs in the job basket. It doesn’t need to be your primary creative outlet. I’m fact, it might be better if it isn’t tied to your livelihood.
Sorry if I’m way off the mark from where your head is at, but I hope thoughts like this are what you’re looking for. If not, my b!
I’m in the same boat and feel the same. It’s just not a great state of things for extension development, and yeah the separate Firefox and Chrome code in my codebase truly irks me.
Remote: OK, prefer hybrid
Willing to relocate: No
Technologies: Python (Pandas, Dagster, SQLAlchemy, Flask, FastAPI, SKLearn, etc.), SQL (big Postgres fan), Svelte, GitHub Actions, Terraform/Pulumi, Kubernetes/Helm
Resume: https://www.linkedin.com/in/raaid-arshad/
Email: raaid@protonmail.com
Hey I'm Raaid. I'm a software engineer who is particularly experienced with data engineering + the backend but full-stack capable. I'm interested in making something that works, works well, is well documented, and helps the world. I'm not interested in pointlessly moving fast to try to make a quick buck. Super interested in anything that aims to address climate or socioeconomic issues.