chipmonkey75

Almost the same experience here; I have great nostalgia for that feeling, and the waiting for hours to finish. Nice to hear similar stories from someone else! I still have my copy of "Chaos", and it was (and still is) awesome, but another book I got around the same time was "Chaos, Fractals, and Dynamics", which included pseudocode, that I had to rewrite into Commodore-64 compatible BASIC.

I'd coded prior to this; I got my Commodore when I was like 11 (the family machine, but I used it by far the most). Mostly typing in games from magazines, but fractals were the first thing that felt like it was "computer science" - something that really explores a new space that just wouldn't be possible without a computer.

I WANT to say "Thumb drive", but I always get ahead of myself and start with "USB" and then either my brain catches up and I say "USB drive" or I lose it and end up "USB thing" or "USB stick".

I think this is the flavor of question that should be asked, tho I'd go further. For one thing, I've always really loathed the phrase "full stack" - if you've ever written a UI that has to drive hardware that requires assembly level firmware, built a CI/CD pipeline to run tests, build artifacts, manage infrastructure, update firmware and send it all out into the world, you _might_ be "full stack", for everyone else it's just a colloquial term for a web front end and a database API developer.

But I digress.

Even in the common context, to be Full Stack, I'd argue that you should be better than the sum of the parts. The lift you get from being able to decide, intelligently and at the speed of thought (without talking to a counterpart on the other end), which pieces of code - optimization, safeguards, business logic, etc. - belong in the front and back end, and how they interact at peak effectiveness, is more valuable than just the ability to build a good API or build a good web page.

Further, a full stack engineer, in my experience, is more likely to reach for tools like websockets, memcached, etc. earlier in a project than typical REST APIs (for example) where the line between back- and front- end require a bit more coordinated architecting, to achieve a richer end result.

But I doubt this is widely accepted. Anyway, my point is I wouldn't focus on either just because; I'd focus on what makes you better by knowing some of both. What can you learn in the back-end to support problems you're familiar with in the front-end, and what can you do in the front-end to make better use of your knowledge in the back-end? That's where full-stack value really lies.

"Breakthrough" is a tough word here...

How about the TurDuckEn? https://en.wikipedia.org/wiki/Turducken Or the Pake (PieCaken, Cherpumple, or whatever you call a pie baked into a cake).

I'm at least half serious -- the arts, including culinary arts, is a place to look. The color indigo comes to mind as an older example (even if science discovered it, it was a breakthrough due to its adoption in art and fashion)... lately Black 3.0 (or Vantablack) may have made enough ripples to count.

Have there been Legal or Political breakthroughs? Was reopening the Cuban border a "breakthrough"? Is electing female world leaders a "breakthrough"? Legalizing gay marriage? Marijuana decriminalization? I could make an argument for any of those.

I'd make a list of what you think "non-stem" areas are (by career, maybe) and look into that. Finance, real-estate, mechanics, art, fashion -- they probably have "breakthroughs" that people outside the fields are not familiar with, at various scales.

Nice; thanks for the throwback, I played the dickens out of that game.

Does this require or allow confirmation from the driver? I would think that an easy two-person agreement would make this super fast... you should only need to involve a central party if the (would-be) driver and passenger don't agree on the refund. (I suppose this would only matter in cases where the driver was already identified and involved, but still).

Another person saying something similar back in July, just for comparison: https://www.cnbc.com/2017/07/20/bitcoin-bubble-dwarfs-tulip-...

There's a lot here...

* He doesn't understand the stack well... If you can't get him to stop coding, Get him on source control and branching, but do peer reviews into master, by which I guess I mean keep that power for yourself, or, if that's contentious, keep a separate branch for yourself, and if you see bugs discuss them with your partner. Dialogue is the way to help here, unless he's willing to defer to your expertise, but good code management and practices will help, and keep him engaged. If he's set on it, he may as well contribute properly.

* Re: not seeing features in the code This is an odd one. What is the proper way for you all to discuss features? If you're not both power users or both completely familiar with the code base then how should he know about a particular feature? Is your documentation air tight? Probably best to agree to a stick-to-it answer, if he doesn't know or thinks a feature doesn't exist... this is true for all salespeople who, as you grow, will grow increasingly unaware of features. Something like "let me take that back to our developers -- if we don't have something that precisely does what you want, we can add it as a feature request" or even "they're constantly adding capability and I may have even missed it in our latest version" or any variation. Again, discuss it, though.

*re: taking out his laptop... If he's the sales guy, and this helps him sell it, then I don't see the problem. If this is costing you sales, and you're sure that's the reason, then that's a different discussion. While this isn't an approach I'd take, I'm not "salesy". Again, discussion is your best option, but if you're asking him to stay in his swim lane, then consider whether or not this is wading into his. Better you're both on the same page, I agree -- if the issue is letting clients see trade secrets then, as before, agree with your partner on a party line: "if we can get an NDA in place, maybe a developer and I can sit and walk you through the code if you have a question about a particular piece, if that will help make the sale".

re: damaging the relationship.... just talk to him about it. Raise concerns -- point out bugs and use that to justify asking him to be more diligent, or pass code by you; point out lost sales and discuss what you think may improve. Approach it as a collaborative effort to solve problems, and hopefully he will take it well.

I'm going to throw an alternate thought out there just for you to chew on... try Slackware first. The common rhetoric is that Slackware is difficult to work with and not for the weak of heart.

That has absolutely been my experience too (I still have my 1995 Infomagic Slackware CD... the horror.)

But are YOU the weak of heart? Perhaps not, coming here to ask such questions. And, IMHO, what you learn from fighting with a more raw linux distribution like Slackware is actually a useful learning tool. You can learn a lot about drivers and hardware systems by having to fight to get them to work.

And as soon as you get sick and tired of it, install something else that someone more forgiving has already mentioned. :-)

My personal preference is to learn by doing, and the best place I've found for this particular task is Kaggle (http://www.kaggle.com). They have a variety of datasets and scored data mining tasks, great forums for every level, code examples, and even a set of tutorials specifically for learning scikit (one of Python's machine learning libraries): http://blog.kaggle.com/2015/04/08/new-video-series-introduct...

I don't have any relationship with Kaggle other than being a semi-active user, but I really dig what they've got going. For a step-by-step approach, start with their blog posts and work on their "Getting Started" competitions. Everything you need is there.