gumballhead's comments

I don't think I have. I was an early employee at a startup that made it through a few rounds of funding. Somewhere in there the ship started sinking and it was pretty obvious.

In the beginning, we routinely worked 60+ hours a week and it didn't really bother me. But when it felt like no matter what I did my efforts wouldn't matter, I lost all my motivation and burned out. But I still couldn't bring myself to quit. I was emotionally invested in the company, our team, and our customers.

The second round of layoffs in a year (a 67% staff reduction) was the final nail for me. After I left I didn't work for at least six months. The first two months, I basically did nothing and got a lot of sleep. Then after that I decided to start doing all the things I never had time for. I cooked all my meals, I exercised, I traveled, I spent more time with family and friends, and I developed some hobbies outside of tech.

That was about five years ago. I've had 3 jobs since then, and I left each of them before a year was up. If the right amount of balance is just to have a job you punch in/out of that pays pretty well, I'm just not that interested. But I also know that there's no way I have another startup in me. For awhile now I've actually made more money with my "side hustle" than I can as an engineer, even though my cash flow is very uneven. So I think I'm basically done with software.

What's cool about this is now that you have a date generator, you can apply all kinds of fun things to your date ranges with Python's standard library.

Apply generator expressions, format them with map, filter out weekends, anything in itertools (dropwhile, takewhile), etc.

I wrote a datepicker to demonstrate some concepts like lazy evaluation with JavaScript generators and it was fun coming up with the test cases.

https://github.com/gumballhead/datepicker/blob/master/src/it...

I worked at a startup that operated for over five years with a similar amount of funding. We had a web app, webpage, native mobile apps on both platforms, marketing, customer service, sales, and our own office that was pretty dope. We had something like 75 employees at the peak. I can't believe it either.

I've never gotten burned out from working too hard. I get burned out by having no say or control over what we are working on or how it's done, and by getting stuck working on low-value tasks for prolonged periods of time. Those projects are the ones that make me not excited at all to come to work.

It's usually because the client / product owner has no idea what they're doing but still insists on making all of the decisions with no input from users / developers / designers. And it sure sounds ridiculous, but it is the norm. Developers are viewed as people who do not want to participate in meetings or planning, and who exist on streams of work to do. If the developers run out of work, they'll go crazy! As long as we "keep them unblocked" and have tasks ready for them, we're doing our jobs and they'll be happy!

This is pretty accurate when compared to my own experience, which really surprises me.

Another benefit is establishing team norms and best practices, which is also a goal of code review, but pairing accomplishes it in a bottom up way rather than a heavy top down way. I've worked on teams where review was a very important part of our process and it was common for code to be under review for days or even longer.

I have major gripes with it too and don't use it unless a project enforces it.

The main ones that get me are the whitespace (4 characters) and restrictive line length (79 characters) rules. They don't work well together, and also don't work well with python's significant whitespace (can't easily break up a line), namespaces, generator expressions, and type hints. All for a subjective formatting decision.

I'll also often see people trying to cram as much as they can into 79 characters with one letter variable names and such while calling that elegant code because it's a "one-liner."

The old options were worthless because the acquisition price per share was below your strike?

Not the last, but near it. Also not the first, but near it. There's a huge difference between the two.

In my experience a sinking ship doesn't start floating, so don't stick around for that reason. It was also depressing to be there after all my friends had been laid off or quit. In reality I probably stayed there two years too long, and it was because of the people I worked with.

I've often wanted to write a compiler that would accept a schema definition like protobufs or graphql as input and generate the required SQL to update the database if a schema change was committed. It would also be read by the application layer so its model definitions were kept up to date.

As you say, there's a tremendous advantage in using triggers to remove data invariants, but then there's also the issue of the schema's state, and it can be prone to error depending on the complexity of the trigger. It's definitely recommended to use SQL's schema inspection to verify and test it. Perhaps even based on schema definitions from protobufs or whatever.

Do you think it's necessary to have a rigorous understanding of all of those topics before creating a machine learning model? And that you don't learn from interacting with it, even if you don't fully understand how it works? For machine learning in particular I think that's pretty ironic.

Thank you for creating these courses and putting them online! I started part 1 a few weeks ago. I couldn't agree more with your teaching style. I'm someone who started college as a computer science major and couldn't finish, because it felt like I was pounding my head on the wall trying to learn abstract math when what I really wanted to do was build stuff.

I finished my degree with economics, went to work in finance, and worked my way to being a developer by first doing advanced Excel, then Access, then database servers, then web development, then native development, and now more math heavy research and development. As the need arises, I keep going further down the stack and gaining more understanding. It's much more natural (for me) to learn that way.

Same, there have been several times I have had a question and someone thankfully asks the exact one I had. And Jeremy does a great job explaining it. It really helps to get at some of the why's behind the magic.

Hiding the name of the company and what they do is my biggest annoyance. Yes, I really care about that. More than their tech stack, and way more than a buzzword soup that poorly describes their tech stack.

Second biggest annoyance is keyword matching me and hundreds of other people and spamming us all, because so many times there isn't even close to a good fit other than your client uses java and I have some Android experience. Most of these people then make me feel like I'm a high pressure sales target, and in many ways I know I am so it's more understandable. But I'm not likely to want to work with you.

The best recruiters I've ever worked with make me feel like I'm the customer and they're doing me a service. Finding good opportunities can be hard, and I probably don't know the market as well as you do. Those recruiters don't outwardly care if I'm not interested in a particular role they thought was a good fit. They say that's ok, what don't you like? What should I look for when I send you opportunities?

I'd be happy to. Can I ask first what you've tried and what you had trouble with? I think a lot of why d3 is considered low-level is that there are lot of external things you do need to know. For example, for me, it wasn't d3 itself but functional programming that I didn't really understand. For those who don't do web development much, it might be DOM (and in particular, SVG) manipulation.

The d3 specific parts are the idea of mapping data to DOM elements (which is the part I think is beautiful), how it uses the data join to do so, and how you use the scale functions to map from data space to pixel space to set the element positions and other attributes.

Feel free to email me if you like -- it's on my profile.

I will say though that it's been a side-project idea of mine for several years now to build a JSX-like templating language that would generate d3 code. Never got around to it.

I guess I'm one of those people who thinks that d3's api is an amazing level of abstraction. It took a bit for it to click for me, but that was mostly because it was my first exposure to functional programming.

If I ever have to make a chart with another language, I cry because I can't use d3. I have reimplemented portions of d3's api in other environments like native Android before. Digging through the docs to find whatever configuration variable I'm supposed to set reminds me of the days of jquery plugins.

Huh... I had a Precision 5510 running Linux and I loved it

My first experience with programming was making a "dump file" editor for my Diablo character in 8th grade with Visual Basic.

Someone had built a utility to dump the memory for your character to a file, where if you knew or could figure out the addresses, you could edit it and load it back into the game. I spent a lot of time changing a value in game, dumping the memory, and running a little diff tool I built to figure out where everything was. Then I built a little editor that could edit your character and item stats with a ui that looked like the game.

Such huge nostalgia for that game. StarCraft Remastered really brought back memories too. Blizzard is so, so good at game design.

I would think the company benefits from a purely financial point of view because they don't need to provide an office or any of the other amenities that go with one.

I personally hate working remotely. Most people don't though so it is viewed as a perk. I've interviewed people before who applied solely because we offered remote. Some of them even lived within a pretty easy commute to the office.

And along the same lines, it's not a great idea to respond to "why are you interested in working with us?" with "because it's remote" even if you really love remote work.