Our families think we do magic and our bosses think we're capable of doing (most) anything. When shit goes south, we tend to get fired, not sued. Fired in an industry where jobs are relatively easy to find with higher than average salaries.

There's no licensure for what we do. You have to go to med school to be a doctor. You have to go to law school to be an attorney. You don't even have to have a DEGREE to get many coding jobs, even if the work risks real human lives. How good that is for society is up for debate. I flip-flop on this. If we make a huge mistake like blowing away a prod database, we're not banned from practicing again.

When the public is out for blood for something a business does, the media doesn't automatically paint a bullseye on developers. The public is not asking to raise the barrier to entry for our jobs, even though there's so many reasons people could make up to argue that a government should regulate us.

I'm just saying that out of all the things we could complain about, there's a lot we should be thankful for. Some would even say we've got it made.

For posterity

I just saw that Azure Devops asks you to run `curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash` to install their CLI.

Pipe something from the internet directly into a sudo shell? Are you nuts?

Dear marketing departments: STOP calling the shit you give away at your booth "swag."

It's a horrid corporate mixture of "fellow kids" and low-mileage white people trying to act cool.

The next motherfucker to give me a branded pen and go "here, have some swAAaag" is getting stabbed with that pen.

I have a co-worker that reports problems by saying "this is broken" or "your change looks bad" and nothing else. There's no recognition for hard work on my team in general, but this guy is a gadfly minus the Socratic benefits.

Did you improve code quality across the project? He'll complain about a function you wrote because he doesn't like how it looks in the code when called.

Did you go out and meet stakeholders so you can learn what your team is supposed to have in the way of milestones and a timeline? He'll complain that it's all impossible and offer no alternatives, solutions or really any new context.

Did you follow your designer's advice on how to handle a corner case in your software? He'll chastise the fact you committed the code to do it in the next meeting because of how bad it looks.

Did you catch him doing one of the things he complains about? He'll complain about you holding up the pull request when we all have to keep moving.

Are you trying to get a task-related question answered in a meeting? He'll interject a sudden argument about code and how easy it is... when he thinks you'll be the one to do it. Very quiet when no one's name is on it, or his name is on it.

Any advice on how to handle guys like this?

Less a rant and more of a rave about the Racket language.

If you haven't heard of it, Racket is a Scheme/Lisp that eases programming language development.

Let me break down why this is handy. When you come to dislike a language, it's because of limitations in the language itself or its ecosystem. That, and you are always obliged to translate your ideas to the terms of the language, the libraries in that language, and the idioms in both. Overall it starts to feel like a cage, because even if you git gud at a limited language, you still might not be able to do the things you REALLY want to do.

Lisps turn this on its head by letting you translate the solution to your terms rather than making you translate your solution to its terms. Lisps are homoiconic, which is a fancy word meaning that all valid programs in the language are also valid literal expressions of data in the same language. The code/data divide collapses and you can at any moment decide "Hey, this code I'm writing? It's data now and I'mma generate stuff with it." That's when you start getting macros and the beginnings of serious metaprogramming.

Racket made this mind-bendingly powerful. To the point that some of the language features make you gawk and say "Ok, but why anyone would ever need to do THAT?!" Some examples include converting compile-time errors to run-time errors and writing your own exception handling system.

But the kicker is that Racket is the only language I know of where you can say "You know what? Racket is sucking at this thing I want to do right now. I wish my language looked like THIS" and then you can use Racket to write your language in terms of Racket, and then your language becomes a valid extension of the Racket ecosystem. Your custom language can still import and use the rest of the ecosystem.

So, in a single Racket project, you can have a typed language, an untyped language, a configuration language and a markup language, and all of them can use the same libraries. It also means that if you have an accountant, ops manager or designer in house, you can write a little language for them that that understand and integrate their understanding of a solution with your system.

Why are relatively few using this box of magic?

Well, for one thing, it's hard. Unlike most, Racket enjoys the benefits of seriously amazing, complete and correct documentation. Which SOUNDS great, but here's a direct quote from one part of it.

"The intent of a cross-phase persistent module is to support values that are recognizable after phase crossings. For example, when a macro transformer running in phase 1 raises a syntax error as represented by an exn:fail:syntax instance, the instance is recognizable by a phase-0 exception handler wrapping a call to eval or expand that triggered the syntax error, because the exn:fail:syntax structure type is defined by a cross-phase persistent module.

A cross-phase persistent module imports only other cross-phase persistent modules, and it contains only definitions that bind variables to functions, structure types and related functions, or structure-type properties and related functions. A cross-phase persistent module never includes syntax literals (via quote-syntax) or variable references (via #%variable-reference). See Cross-Phase Persistent Module Declarations for the syntactic specification of a cross-phase persistent module declaration."

...

Fucking WHAT?

The thing is, I know a little bit about what that means. I read their introduction guide meant for people new to the language, and made enough progress in the reference to understand these terms in isolation. But when I keep running into paragraphs like THAT, I have to review everything again because I just get lost.

The other problem may be that it has the classic Lisp Curse (http://winestockwebdesign.com/Essay...), which means its power is also its greatest weakness. The power of a programming language can grow strong enough that the people who contribute to society using it rarely bother to use each other's work.

Still, Racket has a more complete and cooperative ecosystem compared to other Lisps I've observed. I'm still a total fanboi of the language and would love to get a job using it, but it's probably a long time out.

Thanks for reading. I don't have a particular desire to tell you to drop what you are doing to use it, I just think it's cool and wanted to brag on it a bit.

I feel like this is my first actual rant in that it's a monologue possibly showcasing my emotional baggage. No TL;DRs, so grab a coffee and enjoy.

--

Hey entrepreneurs and people who write about entrepreneurs, can you stop glorifying life-ending risk and workaholism? It's unhealthy and it goes to ridiculous lengths.

Going on about how you maxed out all of your credit cards, nearly lost your marriage, and still ended up rich should not be seen as inspiring. Impressive, sure, but not inspiring. In a fair world, your story should be seen as part of the self-congratulatory silicon valley gold rush culture where people actually believe that lottery tickets and following their own destiny should involve putting up their chance to ever find peace as collateral.

If you made it with hard work and at great risk, then fantastic! I'm still happy for you. I just wish your success didn't buy you the credibility that it does, because you still didn't discover a formula for success or life in general. You took a plunge and survived, which is fun to watch! It's like seeing someone skydive without a chute onto an unclaimed island and keeping that island. I'm just saying that if your story makes a whole bunch of people start skydiving without chutes because they think they'll land on their own island, then we went from hearing an amazing story to everyone just being retarded.

I'll avoid throwing the baby out with the bathwater: If you want financial health and a sense that you are not letting life pass you by, definitely maintain that course and accept risks along the way. Just be reasonable about risk!

I saw an article that started by saying "To start and support your own business, you’ll have to put your career, personal finances and even your mental health at stake." ...Yeah, maybe if you want exponential growth in 5 years because of some kind of cosmic terminal impatience or dysfunctional belief that your moral worth as a person equals the rewards you shoot for.

For people like me who are okay with using a steady paycheck to feed conservative growth and gigs for side income, putting all personal finances and mental health at stake is not an inferior life choice. I strive for flexibility in the event I lose income, and to me the ability to adapt and achieve financial independence is far more valuable than entering into all-or-nothing arrangements in the startup lottery. I won't be filthy rich or stupid famous, but that's okay. I don't need to be.

To those of you on the fence about entrepreneurship, my advice is not to focus on getting rich or famous or even feel the pressure to do so. And it's definitely not to take more risk than necessary. Ask real questions about what lifestyle would make you happy. If it's having a 9000 foot square house, a pool and worldwide admiration, then fine, make the leap. But if you think you're SUPPOSED to have the huge house and worldwide admiration, then I'm telling you that you don't. You are just as important and valuable as a person even while millions salivate over Elon Musk and walk around with inflated aspirations.

And if it helps, good budgeting, wise investments and careful risk management can still get you ahead on lower salaries. Someone making $30k a year but is cautious about savings and staying out of debt can end up just as free and flexible as someone making and blowing $800k a year on luxuries. As for acceptance, having just one person love you for the impact you make on their life is infinitely better than having millions adore you for the (possibly bullshit) image and dream you are forever expected to show them.

To close this out, I'll speak back to the entrepreneurs out there again again: I'm not judging you for making your own life choices. I AM judging your shitty, egotistical need to showcase how great you are for your success when what you did would probably bankrupt the next person to try the exact same thing. And I'm DEFINITELY judging telling people that working 100+ hours a week or risking everything is a necessary part of making dreams come true.

Entrepreneurship is great. Entrepreneurs are full of shit.

Why am I still crazy enough to believe that software development could somehow become predictable even though experience tells me it never will?

Probably has something to do with learning JS.

Manager: Why do you want the promotion to architect?

Dev: I haven't left my comfort zone in nearly a year and I want to have strategic oversight and impact. That and if I have to write any more front-end web code I'm going to fart in your chair.

Manager: We need to establish more of a track record of you handling greater responsibilities.

Dev: That's a really reasonable-sounding way of saying that I need to be doing the job of my current AND promoted self while waiting for you to acknowledge it with the better title and pay.

Manager: I really am rooting for you and the feedback on your work is stellar. Stars just aren't aligned yet.

Dev: I get that there's a bunch of moving parts and I can't force it, but you do realize that this is a candidate-driven market and I can make $20k more a year with the same title by applying somewhere else, right?

Manager: Hey. Careful. Look, I just don't want to look like I'm singling you out for special treatment.

Dev: That's what a promotion IS. Who else has the "stellar" feedback singling them out already?

Manager: Well... Thing is, Rob has amazing feedback

Dev: HOW MANY STELLARS ARE IN AN AMAZING YOU FUCK

Manager: Verbal abuse helps your chances, oddly enough.

Software engineering is the only field I know of where self-deprecation builds credibility.

We are interviewing for a junior engineer, and I was tasked with writing the coding exercise for a candidate that came from a coding bootcamp.

Most of the exercises are React-focused, but I opted to go vanilla: Here's an HTML document with an unstyled form. Style it to your taste, and write validation logic according to these rules. Simple, low enough barrier for juniors to complete, but with enough wiggle room to let candidates show senior-level thinking.

I did the exercise myself and timed my work. 7m 22s. So, ok, juniors should have plenty of time for it (They get 1 hour).

Candidate comes in. Can't finish it. Did not know how to use `getElementById`. Assumed jQuery was loaded in the page and couldn't figure out why the $ function didn't work. Global variables containing dashes, without understanding that dashes could not appear in a variable name. 10 minutes of Googling how to see if a radio button is checked. Conditionals comparing strings possibly containing a dollar amount to hard-coded numerical literals.

To be fair, the candidate did show good empathy when viewing the page as an end user and thinking of possible improvements. Good curiosity, listening skills, etc. There was also decent reasoning skills in React terms. But without a library or framework to shape their thoughts, the candidate was unable to produce a functional web form.

I shared that the candidate has potential but the training cost would be high given the lack of technical knowledge that would aid troubleshooting even if they never left their comfort zone. I ultimately advised to reject the candidate.

Manager says he would not discount the candidate for the coding problems because if they can "build an application without understanding the underlying concepts", that was enough.

I want to be supportive. I do. But I also kind of want to retire.

I keep seeing two philosophies bash heads at work.

1. "Hey, use these tools according to idioms and best practices for that tool. We worked hard getting this to work predictably, and it depends on you doing things consistently."

2. "Go pound sand, I want to do what makes sense for the project. To hell with your nazi conventions."

They're both right, and they're both idiots.

#1 is right because precedents exist for a reason. People did a bunch of stuff with their tools and got things to behave reasonably well, showing mastery over a stack. There could also be actual legal- and infosec- related reasons to following a protocol for changes, and ignoring those precedents invites disaster.

#1 is an idiot because there's a fine line between enforcing consistency and micromanagement. If the idioms they confuse with architecture are making it harder for other people to work, then they need to back off and let context, not ego guide the conversation. Good architecture should enable and encourage people to change the software in radical ways.

#2 is right because Context. Is. King. No project should shape around a tool. Tools should simply and objectively obey their users through good and bad use alike in service of the project. A culture that would oblige you to change for the sake of a tool is not an engineering-driven culture, it's a culture driven by self-anointed thought leaders who learned everything they know about software from Medium.com and Smashing Magazine. To enforce idioms and consistency blindly is turn the best practices found so far into the status quo that prevents change.

#2 is an idiot because there's a baby in the bathwater, which is some of that context they so treasure. By getting defensive with #1, they forget that the more they change, the more the team has to re-learn to adapt. The worst case is the cowboy that rewrites the implementation from scratch, causing QA to re-do ALL WORK and causing engineers to drop everything for one person's way of doing things.

The compromise is hard, but here's what I think it entails:

- Context really is king, but frame your changes in terms understood by how the team already thinks about the project; and
- Make those changes work independent of the tech stack on which they sit.

Doing this requires a solid understanding of, well, SOLID, and lots of patience dealing with ego and red tape.

This may seem obvious to you, but I'm so tired of watching the arguments at work about this degrade software quality and the end-user's experience.

I keep hearing entrepreneurs say that failure is a stop and not a destination. But that always seemed odd to me since entrepreneurs by definition assume the risk for their work, making it possible to ruin their lives with a failure that can quite literally stop them.

We never seem to hear from the well-meaning former entrepreneurs who failed to the point of destitution (unless they are evil, see Theranos), and it seems wrong to give all of our attention to the people who ended up making a ton of money. I feel like those who failed hardest and couldn't recover have valuable lessons to share, and we instead give attention to people who always END UP rich through self-congratulatory narratives of perseverance and hard work.

I want to hear stories from the entrepreneurs who failed and ended up in obscurity. I can't shake the feeling that some of them will have more realistic insights, even if they made bad decisions.

Do you know of any stories like that? Please tell me.

How to Write Software, by Facebook Labs:

Make a framework or library that is useful enough to make money and influence hiring practices under the guise of making sure people are "always learning better ways to write apps."

But make it just limited enough to keep the market (and your competitors) in an eternal state of disappointed acceptance. Release a new major version every time you need them to slow down and give you time to release new stuff first.

Finally, never use terms from CS programs in your APIs, use totally self-descriptive words like "actions" and "portals", EXCEPT for words like "component" which you should help overload to the point of uselessness.

Me: (sees error in ten minute old rant)

devrant.com: No editing! It's over 5 min old.

Me: (learns that deleting latest rant resets the 1 rant/2hr limit)

Me: (deletes, edits, then reposts rant)

Let me pretend this site supports markdown for this therapy session. Ever had a project with an `index.js` in every directory that looks like this?

```
import a from './a'
import b from './b'
...
import z from './z'

export default { a, b, ..., z }
```

If you do this, please stop.

1. `export default` for an object is not the same as having a named export for each of the property names in that object. In this form, someone has to first `import` the module's default export and then destructure it. This screws up tree-shaking and someone expecting a CommonJS module is bound to try destructuring it up front using a `const {} = require()`, which will blow up too unless you've configured a builder to "promote" default exports for ES6 modules. The way this is set up pleases literally no one.
2. I have to edit a file like this every time I add a new module to a directory. If you desperately want an experience where you can `import` against a directory and use named exports for files, you can configure a builder to generate those files for you. Stop making other people deal with this shit just because you don't like having more `import` statements at the top of your modules.

Bonus for you guys: I saw a team justify reducing the number of `import` lines with these index files because they also have a Java-inspired habit of exporting exactly one `default` symbol and nothing else from each module. Which means there are 30+ modules that each contain exactly one function. Half of the work days was file-hopping, and they didn't like the idea of combining modules with related functionality.

Engineer: We need pinch/zoom support for big images. We've been using OpenSeadragon but we didn't like how big it was.

Me: It's 49KB minified. Pretty hefty.

Engineer: Right, so what we can do is fork the repo and delete the parts we don't use.

Me: Fuck you

Engineer: Ok

Me: Our site blasts you with 6.3MB of assets over 233 requests in 5 seconds. Look, if I blacklist this 51KB one right here... man, can you just feel your ass floating out of your chair now that this weight has been lifted? Isn't this worth maintaining a fork that's been stripped to a shell of it's former self?!

Engineer: Just let us know if you need any more context

Me: I CAN FEEL THE SERVERS BEAMING INTO MY NEURONS

Web development is endlessly re-learning the same computer science concepts under new keywords and abstractions made up by marketing departments.

Zyrolasting's Inferno - Layer = 0

Welcome to Hell, or at least an instance of it. It's for programmers, so we call the entrance Layer 0. Clever, right? We have fun here. I'll show you around.

That screen by the entrance was supposed to say "Abandon all hope ye who enter here" with some nice animations and all, but the senior front-end dev is on holiday and the only backend dev that we could convince to try it kinda panicked when he saw our asset build pipeline. He grabbed jQuery and d3 for some reason and tried to animate it himself. After spatting with CSS and SVG at the same time he gave up and shipped what he had. But to his credit, if you tilt your head and cross your eyes you can still kinda read it.

We group people into layers like other hells, but it's not like you are going to chew the same brussel sprout for eternity in Layer 3 because you were a glutton. What we do is assign values to layers. Yeah, values, like honor, safety, love, all the warm fuzzies. All of our staff get split up into teams that claim to support the values of that layer, and we assign the souls that actually HAVE those values to the same layer and make them write software. Stop crying.

Yes, yes, look, I know it's tough, but every soul of the damned forgets that a Hell exists specifically to teach them that death isn't the end. Funny that people keep assuming that's a hopeful outlook.

Now my understanding is that you are here because you shared a single Google Sheet with all customers in your first and only startup as a way to collect their schemas for use in fixed webservice endpoints. Ni-i-i-ce. Unlucky for you that you had enough technical knowledge to be that kind of dumb, because then you probably would lack values and we would have hired you. We originally shipped off the amoral to traditional Hell with the fire and brimstone and whatever because we had enough staff--No, you can't go there instead--but then we got way more brownie points with Satan when we found out we could assign souls to the supervisors they had in life.

The stairs are down this way. Hurry along, there's much to see.

To be continued.

The following dialogue is inspired by a career of similar conversations.

--

Manager: What's the status?

Dev: It works, but I just found a security hole. That contractor did not sanitize all the different kinds of user input and someone approved the PR with "LGTM." A customer can run malicious code and get us in real trouble. I'm patching this now.

Manager: How long with that take?

Dev: If done right, 4-5 days. If done fast, I can squeeze 3.

Manager: Let's not boil the ocean. We need to ship by tomorrow so we can't spend too much time on something that we can fix later.

Dev: Surprising deadline aside, I made a Jira workflow state called "Later" for when you close the ticket after this conversation.

Manager: We need to talk about how your negativity impacts the team.

Dev: Sorry. I just don't want to knowingly release a critical vuln.

Manager: We can introduce a procedural change and have ops vet the documents. We already have a screen where they can approve what uploads get to the customer. If we let a bad egg through, then we'll right-size according to customer feedback.

Dev: Lawsuits are feedback?

Manager:

Manager: I mean

Dev: *Googles "brain parasite symptoms"*

Manager: Hey. The kind of thing you are worried about probably won't happen soon, and we'll be able to handle things in the short term.

Dev: Because it's better that our staff have unprotected sex with the Internet on our corporate network than use a few more days to move everyone along worry-free?

Manager: It's a calculated risk. We're Agile after all, right?

Dev: When it's an excuse.

True horror story: DIBOL software produced by an outsourced team with one SVN branch per customer.