grumpy8

As an interviewer, I like when candidates explain how they're going to solve the problem first. Either on the whiteboard, with comments or pseudo code. It's easier for me to help and guide them when I know where they're going. Some people prefer to start coding right away and, while I won't penalize them for doing so, if they go in the wrong direction without explaining their reasoning there's not much I can do to bring them back.

Landing page looks real nice, congrats

>> It's a bit disappointing to hear, since I personally enjoyed the occasional, honest discussion with smart people

That can still happen, maybe just not on a huge mailing list? :p

The other side of the coin is after you've built a few startups, you see the same pattern coming up again and again. Part of being creative is to know where to focus your attention (I.e. figuring out PMF) rather than wasting cycles on problems with clear solutions.

It's about trade-off. You improve performance at the cost of something else you're not working on. Without the context, it's hard to tell if that cost was justified. I.e. maybe there were 20 critical bugs and the team made the call that perf. was good-enough and it was better to stabilize the software. Most often than not, you can always improve performance and drawing the line is hard.

tech is moving so fast, if you're not learning in your spare time, you'll quickly fall behind. That doesn't mean that you won't be able to find a job though

Email discussion is great for that.. rather than being a "talk-loud" + "fast-thinker" win, it usually comes down to more thoughtful discussions/decisions.

But to your point, I personally just confront the person who keeps interrupting me: - Hey, can you stop talking over me and let me finish my thought? - Dude, you're wrong, and talking over people won't make your argument better.

That being said, I'm sometimes the one interrupting when people keep babbling on and on, and the manager (or meeting lead) doesn't do their job. I try to do it politely by redirecting discussion to the point or summarizing the decision, but sometimes I need to force it and be a bit rude. I don't like doing that, but when you see people starting to roll their eyes or look at their phone, someone needs to step in.

Having a clear agenda with a meeting lead also help to keep the discussion on point while giving a chance to everyone to express their thoughts. If there are bullies, the meeting lead can shut them down.

When the manager or meeting lead is the one being a jerk, then it's obviously tricky. Depending on the culture, you can either politely redirect discussion to the point, summarize the decisions... or just don't attend the meeting. If asked why, can be honest and say you keep being interrupted and might as well work on something else if they don't want to hear your thoughts.

right

amazing product managers often have their hands tied because of shitty higher-management, and rather than improving product they're stuck navigating the internal-political-hell.

Will it start in bronze and then just crush everyone until it's rank #1?

I'm working as a remote engineer and it sucks. So many things are happening in the office that I'm missing out on. MAYBE if all you do is code and someone else write clear spec for you, and you're not a fan of bonding with teammates, then it can work fine. But if you really care and want to optimize for winning and making an impact, remote isn't the way to go.

Yeah, that's a great way to look at it. Just to add to your point, why in hell would someone use Emacslisp? Well, it has a killer app (Emacs / org-mode / etc.) and people learned and used it.

I wonder if ClojureScript -> [Node, Web-js] is how lisp will be saved? Or maybe lisp doesn't need to be saved and it'll always be this non-mainstream language. (To be clear: I say non-mainstream but I don't mean it negatively.)

Unpopular opinion, but I find readability really hard on lisp projects. Everything has to be read backward, and just because you can nest 10 lambdas doesn't mean that you need to nest 10 lambdas all over the place. So the code you end up with is write-only nested-over-nested-over-nested backward-reading code.

Can clean lisp be written? For sure, and it's magnificent. But in practice, it's a total shit show. Basically, what I'm saying is when it's great, it's amazing, and when it sucks it's the worst.. whereas other languages like java/javascript/python have less variance in code quality and range from ["pretty-meh to "good-enough"].

And what's happening these days is the great features of lisp are integrated with "good-enough" languages, and then they become "pretty-good" languages.