ianamartin

How about HTML, the programming language, 's Flying Circus with a very powerful yet flexible and optional type hinting system?

One of the things I learned in the classical music world is that the things we ask people to do in auditions–play the hardest parts of all the most difficult orchestral music without any context–is really creating a new problem that doesn't need to exist.

And in my experience listening to auditions over the last several decades, what you have now is a bunch of musicians who can only do what's on the test. When you try to plug them into an orchestra, they are completely fucked.

My experience interviewing and hiring tech people is that this is one of the worst possible approaches. Anyone who needed to could figure this out. It's not relevant. What you need to figure out in an interview is if the person is curious enough to find the answer.

I don't ask for code or algos in my interviews. I ask about the person. What's your favorite programming language? Why is it your favorite? What do you not like about it?

What's the project you are most proud of? What was hard about it? What made you happy? What did you find challenging about that project?

These are 100% totally humane questions that tell you everything you could possibly need to know about a candidate in about a half hour. Maybe less.

If you can't figure out if this person is technically competent from this set of questions then you aren't competent to interview or hire.

Interviews don't have to be only about how good you are at interviews. They could be about trying to understand if the person would be good at the job and fit in well with the team.

This is a definite risk if you haven't planned for it and got buy-in. But it's a risk that's also fine with me: I don't want to support and develop shitty prototypes that I've whipped up and know to be awful from a maintenance perspective. So if my garbage gets sidelined and I go work on something else, that's also a win and also not my problem anymore.

To be clear, I am not suggesting that the resulting code will be good. But it tends to be more basic and not rely on weird tricks that deeper knowledge of the language will allow you to do.

My larger point is that the first attempt to solve any problem in code is going to suck, so you might as well suck in a different language that won't ever have a chance of being deployed into prod. You learn some things, you get some exp with a new language, and a better frame of mind for solving the problem in a better way.

I'm confused by your example. Sounds like someone who knows (or thinks they know) a language well writing code that is "good enough for now" and causing problems down the road?

Agree about pyenv. It's the best solution by far. Don't leave /home without it.

The time consuming aspects of new product dev are normally not around the time it takes to write the code. It's translating product requirements into solvable problems, logic flows that solve those problems, bumping into unseen edge cases in the product concept, and coming to consensus about what compromises are acceptable in the prototype, bumping into sharp edges while you flesh solutions out because you didn't anticipate a thing when you started your base design or didn't understand the relationships between objects and functionality when you kicked the project off.

These problems that take the most time in any project are mostly human, conceptual, product, and communication problems. Not code problems.

Once you have sorted out all of these problems and solved them, a rewrite in a different language with a better design moves very quickly. You don't have to double the runway or the time to MVP. Time estimations are always wrong anyway. But in my experience when I've gotten buy-in for this approach I would guess it adds 25-30% of actual time overhead to a roadmap. Prototypes always take longer than expected, and an immediate redesign/rewrite takes less time than expected.

Selling this approach to leadership really boils down to clearly identifying the value of developer time. It's not code; it's solving business problems. Once those are conceptually identified and solved, the design and code tend to fall into place without a ton of trouble. The problem is that no one really knows what the business problems are until you try to solve them and really dig into the details.

Prototypes should be understood as the process of defining the problem space and uncovering all the hidden issues that people haven't really thought through just yet. MVPs should be an actual product based on that exploration and problem definition and solving. What I'm suggesting here is really just a process boundary that reflects the difference between the two things.

"Can runway handle that?" is really a lot like asking if you can afford to build a product at all.

One technique I've used as a team lead to limit tech debt that makes it into production is to have devs write prototypes in a different language than what we actually support in prod. This has a few really nice advantages.

1. Devs enjoy getting to use new languages in the real world, and helps keep us learning.

2. The better you know a language, the more tempting it is to take shortcuts. When you don't know a language well enough to write really gross things that work "for now", you have to think carefully about the simplest possible solution to a problem that you can express clearly in an unfamiliar language.

3. You learn tons the first time you solve a particular problem. At the end of the solution, when all of your hacks and tradeoffs are fresh in your mind, you are the best possible person to tackle all the shortcomings and immediately do a rewrite in a language you are expert in.

3. Management really can't twist your arm to just go ahead and transition the prototype to MVP. All you can really do is throw it out there as a public beta with no guarantees while you build the MVP properly using everything you just learned from doing it the first.

4. You can start collecting feedback on what users want included in v1 and get an idea of where the user base is heading with their desires and plan some of that into your design, again reducing long-term tech debt.

If your prototype sticks the landing well enough for management to decide to move forward to MVP, then it's good enough to mark your territory in the problem space while you do the rewrite. You won't lose competitive advantage while it's sitting out there in a separate VPC collecting users and activity.

In a healthy company, this isn't a difficult sell to management. They'll understand the short and long-term value to the company. In more toxic environments, it will look more like you're throwing a poison pill into your dev process—which you kind of are. So, you know, tread carefully. But when people buy in to this process, it works really nicely and has far better long-term outcomes.

I will never again work in a company with a dual CEO/CTO. No matter how well-intentioned and talented that person is, it always leads to a toxic environment. It's an instant red flag that the person is incapable of delegating responsibilities. Separation of duties at the C-level is important. There needs to be some amount of healthy friction in the leadership team to make appropriate compromises. Hope you are able to get out of this situation soon.

That's not how green/blue deployments work. You don't keep both colors up unless you have completely failed to understand the concept.

Green/Blue is all about saving resources and costs, not keeping them around. You misread the cause here. It has nothing to do with deployment strategies.

No. That is not even close to being true. You're confusing None with NULL, like everyone else. Only a very few programming languages make this error.

NULL is undefined. It can't be equal or unequal to anything, including itself, for reasons that should be obvious.

Null isn't empty set.

I am so completely unsurprised that people who don't understand the concept of undefined are telling me that it's actually defined.

If you were my customer, I would fire you.

I love critiques of SQL about implementations of NULL. "NULL is so special that it's not equal to anything, not even itself!"

Like, duh. WTF should NULL be equal to?

Anytime I see people making this kind of argument about "doing better than SQL" I can immediately tell they are pretty much fucked in the head.

Good luck, edgedb peeps. You haven't got a clue.

Thank you.

This is true, and I don't object to this description. Like I said, I'm a grumpy old man.

I'm going to sound like a very grumpy old man—because that's what I am—but if you actually need a tool like poetry, you've really fucked up.

I have a ton of respect for the author. It's really good code and solves a hard problem in elegant ways. But it's a problem that we shouldn't let ourselves have.

It's like a patient talking to a therapist:

patient: I'm really depressed.

therapist: Why do you think that is?

p: Well, I've been having an affair with this woman, and my wife found out about it.

t: How does she feel about that?

p: She's pretty angry at me. It's affecting our relationship.

t: How is it affecting your relationship?

p: Well, she doesn't want to have sex with me anymore, and things have gotten a little weird with the kids.

t: How do you feel about not having sex with your wife?

p: It's depressing.

t: And the kids? How do you feel about them?

p: They'll grow up and understand eventually.

t: Here's a pill you can take every day that will make you feel better.

There are two ways to address this kind of situation. The first way is to give the patient a pill to fix the symptom of depression. The second way is to fix the behavior that's causing the depression.

Poetry (and Cargo and other package/dependency managers) are a little pill you can take to make you feel better about stuff.

But there's another school of therapy. I'm maybe going to sound a little like Zed Shaw here, but there's the "Don't fucking do that" school of therapy.

It's possible to fix the underlying behavior that's causing the pain instead of taking a pill. It's harder and requires more work, sure. But in the long term it is a better, more stable solution.

Since I'm already on a bit of a rant, I'll go ahead and say it out loud: agile is the source of many of these types of problems. You start out with good intentions and then one day you end up married to a thing that was only supposed to be a proof-of-concept, but it got shipped because product team and velocity, and now your life is hell, and that POC now has kids, and you're legally responsible for them, and fuck it, just give me a pill, doctor.

Poetry is a brilliant solution to a problem we shouldn't create for ourselves.

Yeah, that seems off to me too. I don't know of anyone who just goes straight to prod in that way, and I wouldn't take them seriously if they did.

If this economic downturn helps put extortionist companies like Yelp out of business, bring it. The companies that survive or resurrect will be better off without them.

That's the free market. When things are booming, pigfuckers like yelp are free to seek rent and extort. When things go bad, hopefully yelp and yelp-like things go down with everyone else.

I don't wish unemployment on anyone who actually works for a living. But the C-suite and investors of companies like Yelp can take a dive, as far as I'm concerned.

I despise Uber as a company, but I've always loved them as a technology group ever since I used to go to their meetups in NYC. You can always count on Uber to throw a great party and also come up with the worst possible technology.

If you want to know how not to do things, Uber is a very good place to look.

I don't know enough about bloom filters or the math involved to say whether or not you are correct.

But what you're saying sounds a lot like many proponents of various flavors of NoSQL, Eventual Consistency, etc. I.e., it sounds like you are saying that lots of people have been using it for a long time, and it's just good enough. The actual correctness isn't really that big a deal.

I might be crossing domain boundaries here and thinking up stuff that really doesn't matter. I mean, bloom filters have a known challenge. No one was ever supposed to use them except for statistical purposes anyway, and with a known error rate, it's fine to add into your models.

But there's also something that feels a little weird about your point. It sounds like you're saying it's good enough for X, Y, and Z use cases; therefore it doesn't really matter how technically wrong it is.

But again, I could be really off.

I didn't say that any of this was simple or non-trivial. Again, it depends on your priorities and your values as well as your company culture. In fact, I specifically said that testing systems are hard and provided examples of how hard systems are to test. Do you think that Cassandra is a tightly controlled API with a small configuration space?

You seem to feel like close enough is good enough. And that's the cause of the problem I'm trying to address here. Does it really matter if you don't get a notification when someone messages you on Facebook? Or if you get two notifications? Is that particular problem worth testing every possible Kafka configuration? I think that you are saying is no, it doesn't matter.

But I'm arguing a different point. I'm not arguing about whether the testability of any individual feature is important. For obvious reasons: some features really just aren't that important. But not being able to do that, and actively choosing not to understand that system is a symptom of a far deeper problem. When a company makes the choice you have just described, the company has decided to accept that they can't, won't, and will never fully understand their own systems. It's often not a conscious decision, it's a decision made by habit, policy, and culture, which is what's so subversive about it. People don't make big-picture decisions to intentionally have a system that is unknowable/untestable. People make small decisions just like the ones you are talking about that make systems that way. And it's the practice of letting lots of disconnected people make the small decisions of what does and doesn't matter, what is and isn't worth it that destroys systems.

Systems are hard, and I agree with that, but systems are made even more so by bad process.

The being old analogy didn't seem to resonate with you, which is fine. But let me ask you a question about a system.

You have a database. It gets backed up every night. Or maybe every hour. Your job is to take snapshots and store them because that's what you're supposed to do. Yeah, I know, that should be or can be automated. Whatever.

The big picture system and purpose is that you are supposed to be able to recover from a hardware failure/data loss. But that's not your problem. Your problem is that you have to back up the database manually every day. The data team only tests restoring backups from dev to dev instead of prod to dev. Because reasons. Because it's hard.

That type of backup system checks all the boxes you're supposed to check when you get audited. Or at least enough to get through it. But when you really need to understand the system, it fails for all kinds of reasons and people are sitting around looking at each other saying, "well I did what I was supposed to do."

Individuals sitting around making isolated, disconnected decisions like the ones you're talking about (i.e., it just isn't worth it; it's not feasible; it's hard) compound in organizations and create the kinds of systems you don't want to deal with. You're making your own hell here. You seemed to have missed that key point in my earlier comment.

Laziness is a good trait in an individual programmer. But laziness is the absolute death of an organization. Agile is really just distributed, organizational laziness. That's what creates horrible, unknowable systems.

Conflating test/experiment with what the original article claimed to be talking about (and then later walked back) is borderline disingenuous. No one is talking about A/B testing or intentional experiments.

The article is talking about rolling the dice in production deployments and claiming that's fine and something to be proud of. It isn't fine, and it's not something to be proud of. She's the CEO. She should fix her company instead of being proud of how bad it is.

A lot of what we're talking about here is a matter of perspective. And that is the problem I'm taking to task both with you and with the article.

I love articles like this because it's so easy to just add that company to a list of places to never ever work.

I did read the whole article, btw. It's an absolute clickbait title that the author doesn't really mean, and after the article spends a lot of time diffusing the clickbait title it really boils down to, "This is hard, so I give up."

It's true that many--if not most--companies operate this way without ever acknowledging it. And that's bad. It's also true that systems are harder to test than code. But it's not deep fucking magic. Look at the work aphyr does. Look at the testing work that the FoundationDB team did to prove their system's guarantees. Look at the work that security and devops people do every day. She is right that it is hard to test systems. So what? We don't get paid as much as we do because it's easy.

In a certain environment, it is truly impossible to test a system. That's when you have a dev culture that refuses to actually design knowable systems. A much better approach for the article would be to address exactly why systems are so hard to test rather than just saying fuck it. Everything she cites in her list of things that are hard to test are absolutely testable, if you have a knowable system. The real problem here is that agile/scrum/Xtreme programming practices inevitably and by principle do not result in knowable, testable systems. When you have 30+ agile teams on their own sprint cycles and product managers leaning on them to ship features and figure the rest out later, there can be no other result than fragile, broken, unknowable, untestable system.

But the answer to that isn't "Everybody else is doing it so why can't I." The answer isn't to "embrace it." The answer isn't "This is hard, fuck it." The answer is most definitely not to make individual engineers pay the price of being on call because a company's culture and process are totally and completely hosed.

The answer is to address the problems in your company that caused this situation in the first place. The answer is to get your head out of the feature cult and the velocity war and reset your priorities. Systems aren't hard because your engineers suck. They're hard because companies suck. Systems are hard because in most places, no one is allowed to spend more than a couple minutes thinking about the systems.

Agile culture after your early startup cycle is a lot like being a 40 year old guy who's 30 lbs over weight. How did this happen? How did I get here? I was just taking life one thing at a time and getting shit done. Now nothing works quite as well as it used to, it's harder to find dates, and everything just sort of hurts. Would anyone in their right mind just say, "Embrace it! Most 40 year old tech dudes look about like you and are in the same situation! It's fine!" No. Of course not. You have to realize that your priorities have been totally broken for the last 15-20 years of your life, that you really weren't getting shit done, and you have to take some responsibility for your diet and get off your ass and exercise.

That's what companies have to do. They won't, of course. But they have to, otherwise they'll die young deaths. This article is totally correct when she recognizes a terrible symptom of unhealthy companies. But her treatment is hopelessly and tragically wrong.

I've worked in both b2b and consumer spaces. Finance, Market Research, Payments, Education, and Real Estate.

To be fair, this is a blight that infects all b2b/enterprise platforms. The devs and PMs don't care about speed because they aren't punished for being slow. They don't value speed as a feature because they don't have to and don't lose customers because of slowness.

These deals are made by people who don't use the software because they passed some checklist of features and security audits, not because they are good.

Consumer websites, blogs, and especially eCommerce websites can't get away with that without losing users almost instantly.

The moral of the story is that if you are already a big, wealthy company with a big reputation, you can afford to be shit. If you aren't, you're making a big mistake with 3-4 sec load times.

If users are used to waiting, it's because people like you have trained them to be. You list all the things that go into rendering a usable UI as though we don't all know that. Users probably don't, and that sounds like a lot. It sounds like the kind of excuse for shitty load times that PMs use when people do complain about slow websites.

And you can doubly tell how much of a PM you are by assuming that everyone is accessing your product by ad and how much you don't care if they are interested after 3-4 seconds. That's a lot of money you're leaving on the table.

Low-end mobile devices are not the right metric for TTI.

Most people don't realize how fast the web can be because they don't bother to benchmark until they are well into the tooling choices and feature development and maybe someone somewhere decides to complain about speed.

A functional Pyramid app with dynamic templates using Mako, and some db queries via SQLAlchemy can fully load in under 100ms.

The bottom line is that speed is a feature. It's not just one feature; it's your most important feature if you want users. It's more important than developer productivity; it's more important than any other feature. You don't know this because you work in a b2b/enterprise space where users don't have a choice. Their managers make the choice. But if you ever work directly on consumer products you'll find this out really quickly. The difference between ~.5 sec TTI and 4 sec TTI is millions of revenue per minute in eCommerce.

But even though it's b2b doesn't mean it has to be bad and suck people's time away from them. You have the option to learn something and change your priorities. But you won't.

I'm just going to go out on a limb here and assume you're a product manager for atlassian.

No one thinks that's a reasonable target. That's insane. I don't know who that person is or what he's in charge of, but that's the fastest way to being a dead company.

100 ms max on backend processing, 500 ms max on first time to interaction. Client connection speeds matter, obviously. 3-4 seconds is get your fired ass out of here in my world.

Fuck scrum.

Edit: No really, fuck scrum.