I've talked to a team that's doing the dark factory pattern hinted at here. It was fascinating. The key characteristics:
- Nobody reviews AI-produced code, ever. They don't even look at it.
- The goal of the system is to prove that the system works. A huge amount of the coding agent work goes into testing and tooling and simulating related systems and running demos.
- The role of the humans is to design that system - to find new patterns that can help the agents work more effectively and demonstrate that the software they are building is robust and effective.
It was a tiny team and they stuff they had built in just a few months looked very convincing to me. Some of them had 20+ years of experience as software developers working on systems with high reliability requirements, so they were not approaching this from a naive perspective.
I'm hoping they come out of stealth soon because I can't really share more details than this.
Open source and free software was the largest transfer of wealth in the form of techne freely from the craftspeople to the business people.
Knowing how to write a database could make one fabulously rich. Now the person who knows how to make and promote a simple crud app backed my MySql becomes the rich one, while the db people beg for donations.
Linux killed Sun/Solaris and SGI Irix
Developers have voluntarily moved further down in the chain of value - now just describing themselves as primarily a business liaison who can translate to code. All the computer whispering necessary to do all this is freely available and digestible for free.
yeah. i think you can get away with no 1-on-1's for small teams (like 4 people) but by the time you're at 6 or 8, it's probably a good idea. i suspect the OP has reason for believing this, so rather than say "they're wrong," i would say "i'm not sure they explained their environment sufficiently to explain their conclusion."
as for ticket management. JIRA is not your friend. i would rather go with a stack of post-its than JIRA. JIRA does not help you understand what you are trying to do (in my experience.) once you've figured out specific tasks, JIRA can track those tasks, but so can BugZilla or (as my teams are using increasingly) text files checked into the repo.
people often confuse the tool with the process and confuse following the process with making progress. the first rule of issue tracking systems is they should not get in the way of making tasks you need to do visible. JIRA routinely violates this rule.
I generally download from https://rutracker.org/ (need an account to search not for downloading). They have pretty much everything that you can imagine (not just films) and in proper quality too (BD Remuxes etc). There will be no scene releases here because they add russian/ukrainian dubs and subs to almost all films but that's a small problem.
The other one is Heartive which lists torrents from the DHT network with Magnet links https://heartiveloves.pages.dev/ You just click on the torrent icon in the middle top of the selected film and all the available releases will be listed in plain text. The only downside that you need to be familiar with the release tags
Last but not least https://nyaa.si/ if you have a slight interest in anything japanese from manga to anime to much more
Here's the step-by-step guide to self-hosting git repositories:
Change directory to your local git repository that you want to share with friends and colleagues and do a bare clone `git clone --bare . /tmp/repo.git`. You just created a copy of the .git folder without all the checked out files.
Upload /tmp/repo.git to your linux server over ssh. Don't have one? Just order a tiny cloud server from Hetzner. You can place your git repository anywhere, but the best way is to put it in a separate folder, e.g. /var/git. The command would look like `scp -r /tmp/repo.git me@server:/var/git/`.
To share the repository with others, create a group, e.g. `groupadd --users me git` You will be able to add more users to the group with groupmod.
Your git repository is now writable only by me. To make it writable by the git group, you have to change the group on all files in the repository to git with `chgrp -R git /var/repo.git` and enable the group write bit on them with `chmod -R g+w /var/repo.git`.
This fixes the shared access for existing files. For new files, we have to make sure the group write bit is always on by changing UMASK from 022 to 002 in /etc/login.defs.
There is one more trick. For now on, all new files and folders in /var/git will be created with the user's primary group. We could change users to have git as the primary group.
But we can also force all new files and folders to be created with the parent folder's group and not user primary group. For that, set the group sticky bit on all folders in /var/git with `find /var/git -type d -exec chmod g+s \{\} +`
You are done.
Want to host your git repository online? Install caddy and point to /var/git with something like
Named arguments don't stop the deeper problem, which is that N booleans have 2^N possible states. As N increases it's rare for all those combinations to be valid. Just figuring out the truth table might be challenging enough, then there's the question of whether the caller or callee is responsible for enforcing it. And either way you have to document and test it.
Enums are better because you can carve out precisely the state space you want and no more.
Back in the 1990s there was a huge influx of people into web design who knew how to design for print at a "retail" level (design an ad or a poster) as opposed to a "wholesale" level (create a design system for a magazine) and as a dev I would frequently receive a PSD from a designer and figure out how to abuse the primitive HTML was had then to make something that looked like that.
Today Figma has replaced PSD but the same pathologies remain. A new version of iOS comes out and the armchair quarterbacks want to go over the appearance pixel by pixel but they're not really interested in UX design in the sense of designing a sequence of interactions to attain a goal.
As a dev, what I want from designers is design systems, guidance on what everything is supposed to look like that I can implement whatever I need to implement and have it look like a designer was involved. I blame the tools though less than I blame the designers who are just not inclined to think systematically. CSS was definitely designed to create design systems (css classes used in a disciplined way reflective of semantics) but tools like bootstrap, tailwind, Emotion, and the MUI theming system all represent regressions away from that ideal but I don't think those tools make bad designers, it's the other way around.
I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET.
I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.
I self-host a (non-critical) mail server and a few other things and occasionally look at live firewall logs, seeing the constant flow of illegitimate traffic hitting random ports all over the place, some hitting legitimate service ports but others just probing basically anything and everything. I decided to setup a series of scripts that detect activity on ports that aren't open (and therefore there's no legitimate reason for the traffic to exist) and block those IP addresses from the service ports since the traffic source isn't to be trusted.
Something that came out of analysis of the blocked IP addresses was that I discovered a few untrustworthy /24 networks belonging to a bunch of "internet security companies" whose core business seems to depend on flooding the entire IPv4 space with daily scans. Blocking these Internet scanner networks significantly reduced the uninvited activity on my open service ports. And by significantly I mean easily over 50% of unwanted traffic is blocked.
I'm semi-aware of the futility of blocking IP addresses and networks. I do believe, however, that it can significantly reduce the load on the next layers of security that require computation for pattern matching etc.
TLDR. Send an email before 15th May to:
arbitration-opt-out@discord.com
"I am confirming that as of the date of this email, I am choosing to opt out of binding arbitration to settle disputes with Discord".
Make sure to send it from the email you use for your Discord account.
Consider the large companies with hiring processes intended to try to acquire each employee at the minimum compensation each individual will accept.
I suppose it shouldn't be any surprise if the company (or a manager within the culture of that company) also tries to get the maximum value out of each employee according to what each individual will endure.
Now consider closer to home for HN. Typical pre-seed/seed startups, where the first couple engineering hires might be offered 0.5% to 2% in ISOs, although critical to getting to MVP. While the founders, who started months earlier, get an order of magnitude more equity, and under better terms. Not because that's fair or fosters an environment that deserves much loyalty, but because they're trying to get the employee at the minimum cost they'll accept, even to the employee's disadvantage.
Reddit is very wrong about almost every discipline I have experience in and can speak on as an expert. I feel like I'd suffer from Gell-Mann amnesia if I paid it any mind.
I think there's a good degree of pseudo-intellectualism on the site. Not necessarily in the conduct, but in claims of knowledge and the certainty they present it with.
There was a period in my life I've been active on Reddit myself. Looking back on that period in my life, I presented many strong and celebrated opinions there without much basis in reality. I'm not beyond blame for this, just stating an observation.
From my perspective, Reddit works as a validation machine, where validation is given somewhat randomly. It's like a self-service bias entrenching device. So perhaps it's natural to see pseudo-intellectual content there written by people such as my younger self.
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
-- E.W. Djikstra
If you want simplicity you have to do hard work. It doesn't come by simply removing libraries. Some of that may be incidental complexity and you will get better performance from it. However the core problems themselves, the essential complexity of the problem: to make a solution that solves it in a simple way requires thinking. And if there's one thing I've learned in my career: people hate thinking.
Businesses tend to prefer quick solutions and will pay whatever cost to have it now rather than later. Elegant, simple solutions require time and thought. That is expensive and slow. Since businesses pay our salaries we do what we can and we slap on a library or use a framework and move on.
Homoiconicity wins in my book. Clojure is the best proof I have of this: What mattered was not the linked list or the cons cell. What mattered was that all code was just nested calls to functions and macros with the SAME general form: (function arg1 arg2 arg3 ...)
Expression-based programming using this core form is trivially easy, and makes immutable data structures downright pleasurable to work with. It also makes code generation easy, though I've never taken full advantage of it; even so, a DSL made of runtime functions is not only possible, but a natural extension of anything you're already doing. Backing those homoiconic expression forms with typical high-performance data structures like arrays and hash maps, as Clojure and Janet do, is a winning formula for making complex tasks simple.
All the patterns of yesteryear for modeling problems begin to look quaint when your program eventually just becomes a pyramid of expression calls, with `main` at the top and database hits at the bottom. The organization of the stuff in between really just becomes a question of standardizing function signatures and organizing modules so humans can easily navigate them.
Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.
The reason I put stateless code as the highest priority is it's the easiest to reason about. Stateless logic functions the same whether run normally, in parallel or distributed. It's the easiest to test, since it requires very little setup code. And it's the easiest to scale up, since you just run another copy of it. Once you introduce state, your life gets significantly harder.
I think the reason that novice programmers optimize around code reduction is that it's the easiest of the 4 to spot. The other 3 are much more subtle and subjective and so will require greater experience to spot. But learning those priorities, in that order, has made me a significantly better developer.
Something that I've noticed recently is that in my work life, I'm finding there's more bureaucracy in what I do, mostly in the name of "efficiency". When you encounter a problem to solve, there's often a process already defined that is most efficient (or at least thought to be most efficient), when accomplishing tasks, there's a pre-defined way of laying out the tasks (i.e. tickets), updating them, reviewing them, and organizationally figuring out what's best to do next.
In my opinion, these processes are an attempt at organizational efficiency. However, the flip side is it reduces personal agency for the worker. There's little room to diverge or think about what you're doing. If you diverge, such as taking longer to do something than what was prescribed, or using a different pattern to solve a problem, there is a cost to you within the system. You must explain why, which itself "costs" something. In a sense, you're punished for doing things differently.
That loss of personal agency is absolutely soul-sucking. You feel like a machine, again at the cost of organizational efficiency. Slack is definitely important because it lets people acquire some sense of personal agency again.
Goal-oriented work, creativity and motivation definitely have a difficult relationship.
In programming, I learn the most things simply by experimenting at home on my own. I'm thinking about switching jobs, so I wanted to learn some new frameworks and concepts to help with that, and I decided to make my personal projects a bit more "professional". Use continuous integration, focus more on web stuff, build and automatically deploy containers and so on.
Big mistake. I don't want to spend my leisure time fighting with tools, debugging build processes that break all the time, make sense of docker's tagging system and so on. I don't mind programming all day, because I love programming, but I do mind working all day.
So I let it go. I'll come up with my own tools. They won't be great, but I'll have fun making them. And then it'll feel nice using them. And then I'll work on whatever excites me.
Once in a while someone will ask me "how do you know all these things?" and my answer has always been "I don't know that much, I just randomly got interested in this particular topic and decided to play around with it". Over the years/decades, that adds up!
> It’s surprisingly rare for things to split like that.
THIS. The product is blended and so must the teams be. Among all the full-stack developers I've worked with, the "frontend" or "backend" designators tended to describe preference or strength, rather than limitation.
Throw in Bertrand Russell's Liberal Decalogue and we have a great foundation:
1. Do not feel absolutely certain of anything.
2. Do not think it worth while to proceed by concealing evidence, for the evidence is sure to come to light.
3. Never try to discourage thinking for you are sure to succeed.
4. When you meet with opposition, even if it should be from your husband or your children, endeavor to overcome it by argument and not by authority, for a victory dependent upon authority is unreal and illusory.
5. Have no respect for the authority of others, for there are always contrary authorities to be found.
6. Do not use power to suppress opinions you think pernicious, for if you do the opinions will suppress you.
7. Do not fear to be eccentric in opinion, for every opinion now accepted was once eccentric.
8. Find more pleasure in intelligent dissent than in passive agreement, for, if you value intelligence as you should, the former implies a deeper agreement than the latter.
9. Be scrupulously truthful, even if the truth is inconvenient, for it is more inconvenient when you try to conceal it.
10. Do not feel envious of the happiness of those who live in a fool’s paradise, for only a fool will think that it is happiness.
> “Not having to” write types but having to think about them anyway is like doing math “not having to” write anything down and doing all calculations in your head. How is it an advantage to not use pen and paper to track down your train of thought as you do a complex calculation, and instead be restricted to do it only in your head?
If dynamic type systems are like not having pen and paper, then static type systems are like a teacher forcing you to "show your work" by writing every little step on pen and paper, no matter how obvious. What's interesting is finding good middle grounds.
