gumballhead

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.

My Precision 5510 (last year's) gets almost 7 hours, and I have the high res screen too. I also have the GPU but only run it for compute.

I did go for the m2 drive so I could fit the upgraded battery, which is about the max size you can fly with. I love that laptop and to me it's the closest you can get to an MBP.

There was a story a few years ago around my area where a kid who was in trouble with his parents took his father's work truck without asking to get cigarettes. His father called it in as stolen to teach his son a lesson. Well, he ran from the cops and they shot him.

If you're going to send a group of people armed with guns into a harmless but tense situation there's at least a chance that something really bad is going to happen.

And for sure it shouldn't be like that, where cops can and will shoot you given any justification. But "swatting" isn't a funny prank at all and it's sickening that it's even a thing.

Probably money and time. If they are common shareholders they likely had to pay out of their own pocket to exercise their options and also had to pay taxes on it. Not great news at all.

With rent at $230/ac and land prices at $7k+, it's about a 3% annual return. So it's more like 30+ years to break even.

It is high, but typical. With rent around $200 an acre, land only generates around 3% annual cash flow at that price. And even that rate is killing farmers right now.

That price per bushel is for soybeans, not corn. Soybean yields are much lower, like in the mid-50s to low 60s on average. The marketing year average price for corn in 2016 was $3.30. That cuts your revenue number to $670. With production expenses most farmers are lucky to break even right now.

“I don’t want financial planning people spending their time importing and exporting and manipulating data.“

That is literally all I did when I was a financial analyst and is how I became a programmer. This should be automatic, I thought.

I often get sympathetic comments for being an Android developer because of this. It's honestly not that bad. Android provides backwards compatible support libraries for whatever SDK you're supporting, and was designed from the beginning to handle diverse screen sizes and hardware.

By far a bigger problem is manufacturers shipping their own version of Android that is sometimes incompatible with the SDK. I've had to implement some ugly hacks for Samsung before, which is unfortunate because of how popular their hardware is. It's becoming less of a problem over time though.

Exactly what I was thinking when I read that. Original Android didn't go far enough, then RxJava and clean architecture went way too far. Fortunately the new architecture components like LiveData and ViewModel coupled with kotlin (especially coroutines, wow where have those been all my life) are simple to use and understand while providing the right level of abstraction. Android development has become really nice lately.

Commoditization and industrialization is also just not good for farmers. Why are we growing all this corn? No one seems to want it.

Farmers can't make money when corn is down at $3.50 a bushel (futures). And local prices are much, much lower because the elevators are full from back to back record crops. We have a $.60 basis in my area, which is historically very high.

What's good for farming is no longer good for farmers. Their best recent year was 2012, a 100 year drought when corn prices went north of $8. We had 120bu corn in 2012, which is $960/ac revenue. This year even at 200bu corn we'd be looking at about $600/ac revenue. Good luck with that. You're just farming for insurance payments at that point.

And I forgot to mention that about 40% of all corn use goes to gas tanks as ethanol (the rest is about 40% livestock feed and 15% exports). So even with that demand source, which is itself a dumb idea, we can't clear the market at a price farmers can live on.