So, I'm not familiar with TypeScript...but I am familiar with other languages that use this mechanism (e.g., Scala) and there is a big difference between a "None" value (on an option type) and "null" value (on a reference).

Namely - you have to "unpack" an option type before you can access the value and the act unpacking (e.g., via pattern matching) forces the programmer to write the null check because the most natural way of accessing the data doesn't allow you to avoid it.

Now - that said - there are things like Option[T].get() (e.g., in Scala) which *will* unpack the value in an unsafe way. The distinction is still useful though - you generally shouldn't be using ".get()" and it's not the normal way of interacting with Option[] types.

This is opposed to the standard way of accessing nullable values (in, for instance, Java or C#) where the most natural approach to access a property or method on a reference requires you to first check for null.

Additionally - if you are writing a method in these languages which doesn't accept parameters of Option[T] but only accepts parameters of type T, then you can assume you are being given a non-null value because the expectations are very clear. Again, in C# or Java, there is no distinction here and null might very well be a valid value and there's nothing the compiler can do to help you find those types of mistakes.

We're trying to sell a couch right now - the only responses have been scammers.

My wife has been handling the messages, but my understanding is that it works like this:

(1) The "buyer" says they can't pay cash, that the only payment methods available to them right now are (something that can initially succeed, then fail later - e.g., a check, PayPal, etc.).

(2) They'll send their mover to pick up the item once the transfer has succeeded.

But...how do they get any money? My understanding is that there is a step 3 - they ask you to pay the "mover" who comes to pick up the item, after giving you more than you agreed to in step (2).

The easiest way to make this work as a scammer would be to be the "mover" yourself, take the money and the item and then try to sell the item yourself. But that leaves a really obvious trail, so I'm not sure if there's more to it or not.

I have to second this. I love to type on my CODE keyboard, it feels great.

I actually look forward to using it.

That said - at work, I use a dinky HP keyboard, because the CODE keyboard (even though I bought the quietest one they have) is still very loud.

Yeah but, in this case, it didn't "just fucking work".

It stopped fucking working, so we had to fucking do something about it.

Maybe, eventually, we'll fucking figure out the fucking sensory & feedback systems, but for now, it's pretty fucking awesome that we can get fucking artificial hearts if we fucking need them.

That said, having fucking wifi connectivity in your fucking heart does sound fucking scary.

Hah. Whoosh. Two days off = Saturday / Sunday. Man, I fell into that one :p

That's very good for you, but it's also not typical.

(1) Not everyone can draw a cartoon version of themselves that would be aesthetically pleasing.

(2) They animate the face to match captured motion.

Now, granted, for (2) they could instead analyze a cartoon face drawn by a human and figure out how to animate it...but I'm guessing you would think THAT was a waste of time as well.

I used to work in creating educational software. Having this technology would have been a boon for some of the stuff we were planning.

You sure are down on what, I think, are interesting research projects. I don't think anyone could have ever been under the impression that Song Smith would or was intended to replace actual composers.

So....this is a white kid and (although I'll admit I might have missed it)...I didn't see anything that indicated he might be a Muslim.

The way you train a "replacement" is the same way you train any new employee on a software team.

Start by giving them small tasks. Let them work their way through your backlog of things you haven't gotten around to doing. Bugs are great candidates for new members of the team. Ease them into the code base. Do code reviews with them before check-ins.

Personally, I like to do some pair programming during the first couple of days to help them set up their development environment and familiarize themselves with how I've been working on the code.

Unless this is a trivial project, you're never going to be able to impart all of the knowledge you have about it. If they're worth anything (and you're worth anything) it won't be so complex that they can't figure out how to extend / maintain it. Your job is to give them a leg up and ease the learning curve.

Be open and honest and helpful. The reality is that this new guy is either able to replace you or isn't. If a novice is able to successfully replace you, maybe the project has matured beyond the need for a senior-level developer and it's time for you to move on.

If that's not the case, it will become abundantly clear in due time and they will treasure you all the more for having seen the difference your skills & experience provide.

I can't believe this is marked as insightful.

Worries about your current job don't trump other factors when deciding whether or not to create a human being.

Sure, the timing is unfortunate, but there are a million other concerns that might far outweigh the stability of your current position.

Depending on the type of work you are doing, it might be that the majority of your architecture is already in place (e.g., web frameworks like Rails). It could also be (as someone else implied) that the patterns are there and you aren't recognizing them. I hope you don't mind, but I checked your profile and it said "java web dev". You're not going to escape using Java for just about anything without using design patterns. You may not be implementing them, but the libraries you are using make use of them extensively.

The "valueOf" function in Java is a static factory method. Why does it matter that it has a name? Because if you and I both know the name, we can discuss it more efficiently.

For instance:

Jill: "You have a lot of different constructors for your class, have you considered using static factory methods to make it more obvious what is going on?"
Bob: "We could do that but maybe we should consider using the Builder pattern instead."
Mike: "Whoa, wait a minute. I think Builder might be overkill for this situation."

If our heroes don't have a common understanding of "static factory method" and "Builder pattern" the discussion becomes more lengthy. Having a common terminology for patterns facilitates discussion.

People can describe a solution to a problem they encountered. Maybe their solution is a known pattern - great! They don't have to describe it themselves, they can point you at a wiki article and then describe how that solution worked in their specific situation. Maybe their solution isn't a known pattern - interesting! They can describe it in relation to other patterns and discuss the pros & cons of their approach versus the others.

You can look up implementations of the pattern in the language / framework you happen to be using and see how other people have approached the problem.

You can read people's thoughts about using the pattern, "Well, we considered but ended up doing something closer to ." Maybe you hadn't even considered "pattern 2" and maybe it's a better solution for your situation.

And if people aren't using the names, you can still sometimes listen to their description of the system and short circuit a whole bunch of (high level) analysis. "Ah...that thing he's taking two pages to describe is a Factory. Got it."

As far as using the patterns as a catalog...yes, that can be a problem. There is real danger of ending up in a "solution looking for a problem" mindset. But, paired with maturity and discipline, familiarity with solutions other people have used for a variety of problem can't hurt.

Yeah, shutting down off shore drilling is insane. I mean, it's not like anything happened.

Right. Because who in their right mind would want to, for instance, hire Herb Sutter?

Just because you are working for someone doesn't mean you are their bitch. Someone with marketable skills will move on to something else if you treat them poorly. Good luck keeping your company going when all of your employees are the kinds of people that don't have any better options.

Just reiterating what other people said but...if you don't let your best employees help you find people to hire, I think you're going to find that (before long) your "best" employees won't be all that impressive.