jbrains's comments

First, that sounds hard. I'm happy that you're asking for help and I hope you find the help you need.

Next, you'll probably get a bunch of advice about leaving immediately, how you don't have to put up with this nonsense, and so on. I consider this advice well-meaning, but it might not take into account the complicated web of constraints that you face, so I recommend interpreting "You should get out there now!" as something more like a supportive "You don't deserve to live like this!" True, but not necessarily enough on its own to formulate a plan to address your quandary.

In response to your final paragraph especially, it sounds like you need to have a real, frank conversation with someone who can help you navigate this situation. One in which you can get into the complex details of the situation and balance all your competing needs and desires. I say this because, sadly, you will not be able to solve this problem by running away from it, because it will find you again and you'll be even more tired and even less interested in dealing with it. You probably need more than "Get out and take your people with you".

If you'd like to try to have this conversation, then I think I can help. You can start with my handle here, search the web, find out more about me (to judge for yourself whether I might be able to help you or I'm full of shit), and then contact me. If you think we might click, then ask me for help. Ignore anything that you see along the way that looks like a price.

Meantime, any advice I can offer will sound like a platitude, so I won't bother. The reality of the situation is much more complex than that. Instead, think about what you'd like to have happen and maybe we can figure out how to make it happen.

Peace.

Read the book "The E-Myth Revisited" before you decide to go solo. You might be having an entrepreneurial seizure; it's not necessarily a bad thing, but you might prefer to be better prepared for what happens after that.

> I feel guilty when our customers have repeated bugginess in our app.

You might be feeling over-responsible for the bugginess in your app. If you did your job perfectly, which forces in the environment around you would still cause you to ship bugs?

In your shoes, I would still want to do everything in my power to limit the bugs that I ship---that's why I practise TDD, for example---but I look carefully for the boundary between what lies within my control/authority and what doesn't, then I refuse responsibility for what doesn't lie within my control/authority. And that was a more-than-a-decade-long change in my mindset.

Not everyone likes TDD; I don't mind. I have a system that helps catch my mistakes sooner, so that I limit the associated damage. I have a very effective system, which I trust, and which therefore allows me to work aggressively: if I can recover from failures inexpensively, then I don't need to agonize over failures. If I drive the cost of failure down close enough to 0, then I don't need as urgently to limit the probability of failure.

What can you do in your work that might help you limit the cost of failure? If you had that, maybe you'd feel less guilty about making mistakes, because you'd done significant work to limit the cost of those mistakes.

Good luck.

I routinely run a combination of Slack and Discourse for my online communities. I can move interesting Slack threads into Discourse for longer-term and more-thoughtful discussion.

The immediacy of chat has its place, but so does the semi-permanence of something like Discourse or Groups.io or a good, old-fashioned mailing list.

This happens all the time.

We have a vague notion of a thing, so we call it "X". Later, as we learn more, we realize that we can think of X as a category of things, and that one of those things, annoyingly, should probably be called "X". Now we have a problem. Some people will call the thing X and some people will continue to call the category X, because they read our blog posts from five years ago, because they were so popular, because we are so awesome.

This is a sign of a good thing, even though it causes confusion. Now we have to roam the countryside saying "I know we say 'X' to mean this general thing, but we also say 'X' to mean that more specific thing. I'm really sorry. It's my fault. I recommend that you say 'Y' to refer to the category, but be prepared to read 'X' on the web. It is what it is."

It is what it is.

I agree. I think you've overstated how many people take that position, but I agree. By the same token, I find it unfortunate when a person turns "TDD doesn't work for me" into "TDD is a bad idea", which DHH has certainly and explicitly said in his articles on the topic. His title "TDD is dead" simply makes one group of people cheer mindlessly and another group roll their eyes. It doesn't help the conversation.

That said, I understand meeting extremism with extremism. I don't think it works, but I understand it.

I think of it the other way: if it's easy to write code that "understands" your code, then it's probably easy to understand your code, because you can encode (ha!) your understanding precisely enough for a computer to execute it and accurately enough to pass tests.

I don't quite buy the contrapositive, though: I easily understand small functions that touch well-named global variables, as long as it touches maybe 1 or 2 of them, but we wouldn't call such a function particularly "testable". At some point, poor testability and difficulty in understanding correlate, but we can easily exhibit entire classes (ha again!) of easy-to-understand-but-difficult-to-test code.

If we had a catalog mapping test/testing problems to design smells, perhaps we'd find it easier to argue our position more convincingly. A bunch of us keep meaning to write that catalog, but I haven't seen it yet. :)

"V" means "viable". The profit motive encourages businesses to race to the bottom of "viability" just as with quality. So it will always be.

I like to pair. I like to talk about pairing. I have worked with people who don't pair well. I worked with one person whose wife noticed that his entire personality changed for the worse when he tried to pair. He stopped pairing.

You don't like to pair. You don't want people to try to pair with you.

So far, I'm with you.

How do you get from there to "if you ever talk about pairing, you're incompetent and horrible"? I have trouble with that part.

TDD is a fundamental learning technique. It teaches the principles of modular design. Notice! One can learn modular design in a variety of ways. I make no claim that TDD is "the only" nor "the best" of these, but I claim that it works for enough people to merit attention.

Learning requires investment. Investment carries risk. Risk aversion/tolerance is a very personal and contextual thing. There's almost no point arguing about when it's good to be risk averse and when it's good to be risk tolerant, because of this heavy coupling to the context. Better to be aware of the phenomenon and work things out case by case.

Some people generally don't like to learn. Nothing you do will force them to like to learn. You can invite them to try to learn; you can try to make it comfortable and safe for them. That might work.

Some people find such value in a learning technique that they continue to use it, even after learning 99% of what they will ever learn from it. Continuing to use the technique provides them comfort. Whatever works. Others eventually break free of the learning technique, knowing that they can fall back on it when they feel pressure.

I care about this: people who want to practise TDD should be free to do it; people who don't want to practise TDD should not be forced to do it. Everything else is noise.

"Better to leave it in the social sphere." I don't consider this some idle philosophical stance, either. The technical solutions don't actually solve the problem, since people work around the attempt, and they create additional problems, such as the one at the heart of this thread. I still marvel at how common this combination is: the "solution" doesn't actually solve the problem and creates others that wouldn't otherwise exist.

I see a lot of comments here of the type "You have to know when to refactor". I don't do it this way. Instead, I rely on a willingness to undo a refactoring when I see that something else might work better -- and even to undo that when I decide that I've got that wrong.

I have no problem extracting as in "WHEN REFACTORING GOES BAD" -- although I might wait for a third copy because removing the duplication -- because I want to see whether a useful abstraction would emerge. On the other hand, as soon as I recognise that one of those copies wants to change in a way that the other does not, I'd simply inline the method and let them diverge. I don't consider this a problem.

It seems as though some programmers believe that, one they extract something, it needs to remain extracted. No. It's only "cargo cult refactoring" if you stop thinking.

Most importantly, refactoring is experimentation. It's a kind of Mechanical Turk-based genetic programming-oriented style of designing, except that you have heuristics you can follow. That means that you'll go down the wrong path. THAT'S OK! as long as you allow yourself to backtrack. Remember: refactorings are small, reversible design changes. That means not just that one can undo them, but that one is willing to undo them.

I just realised that the statement "it's still an if-then construct" illustrates a common problem among people practising OOP: conflating implementation with interface.

The OR is not an if-then construct. If anything, the if-then construct is a specialised use of OR, given than if-then-else is literally XOR.

Both are an implementation of the interface "coalesce a value with null/0/false".

I only mention this because it points to a lack of precision in our thinking which I see time after time get in the way of using OOP/OOD effectively. Maybe that's a failing of OOP, but I think that if it were, it'd be a failing of programming in general, too.

This helps explain why I teach OOP the way I do: start by following the rules of removing duplication and improving names, which encourages the programmer to ask ever-more-interesting questions about what tools are available to help follow those rules, which encourages the programmer to learn OO theory as needed, rather than having it shoved in their face all at once. This just-in-time learning leads to longer-lasting understanding for many (most?) people.

Yes, but that's probably a matter of familiarity over clarity. This is a perfect time to use the irrationally-dreaded ternary operator.

  param = object.property.nil? ? default_value : object.property

Verbose, although less so, but reveals intent almost perfectly. Would be better if the colon were "else" or "otherwise".

Not an if statement, but unnecessarily clever code that doesn't reveal its intent. An example of the tension between general clarity and a concise, well-known idiom. The kind of thing that makes C++ impenetrable to those who don't write it regularly.

I'd rather add a method to Object/Nil called something like #or_else so that we could write

  param = object.property.or_else(default_param)

which, though still terse, at least describes what's going on.

The only person who may feel pain is the person with the greatest problems in the world? Really? By whose measure? Where will we track this? How will we update the leaderboard?

I know: I'll buy theonlypersonintheworldallowedtofeelpaintoday.org and you set up the hosting. Deal?

The dearth of empathy built into this "comment" is disquieting.

You make many assumptions here. Can you count them? What if you've got only half of them wrong?

No matter how good we have it, failure will disappoint us. I don't see a problem with that. Even if that failure is good for the universe, it will disappoint us in the moment. I think that's just human nature, no?

I don't understand it when someone tells me, "Don't feel so bad." Fuck you; I feel bad right now. Just because you wouldn't feel the same amount and kind of bad doesn't mean that I have to stop. If you want to judge me, feel free, then fuck off.

Stories like this highlight a particular application of Sturgeon's Law: 90% of everyone is crap.

I generate about $25k/year in mostly-passive-income from single family rental homes. I average 20 hours/year maintaining this income stream in answering email, collecting invoices for my accountant, and making the occasional tough decision about renovating/repairing/waiting.

I got there after placing subcontractors for about 2 years with various companies, which built up the cash reserves that let me purchase the rental properties with no mortgages.

I got /there/ by inviting some young dude to a conference I organised whom I'd met at another conference. He and I worked together to match talented young programmers with companies that wanted them. Nice work if you can get it.

Maybe this: in "draft mode", you automatically commit on all changes in pass/fail state. Then, at some point, you "publish", at which point you squash all the commits from commit X to HEAD whose message matches "[ON RED]".

I imagine git rebase -i X | sed -i "magic happens here" would do the job.

I have started doing this for my training courses. When I demonstrate live, I commit to git. I use some variation of "FAILING" in the commit messages to call attention to "red" commits, in "violation" of the usual rule that tests pass 100% in all commits.

azundo, I know my examples aren't web apps, but do you have time/energy to explore any of the branches in this code base[1], read the commits, and give me feedback on how easily you follow it?

[1] https://github.com/jbrains/WorldsBestIntroToTdd-Tallinn-Janu...