And most people problems are communication problems. Engineers aren't engaged with the product vision or the customer base, and are allowed to silo themselves. Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop. Sales and CS fail to understand the cost of their promises to individual customers to the timelines of features they're hungry for from the product plan. Goals and metrics for success fail to align. And thus everyone rows in their own direction.
The solution usually isn't "better people." It's engaging people on the same goals and making sure each of them knows how their part fits with the others. It's also recognizing when hard stuff is worth doing. Yeah you've got a module with 15 years of tech debt that you didn't create, and no-one on the team is confident in touching anymore. Unlike acne, it won't get better if you don't pick at it. Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.
Oh man, I remember in 2000 when I first started working in the industry we had this database build process written in Java that took almost 30 days to run. The delivery schedule was monthly, and if anything went wrong we'd have to restart from checkpoint and the database build would be late. It also pegged a 32-CPU SMP DEC Alpha machine for the entire time, which was, well... CPUs would regularly (once every other build or so) cook the socket they were in and have to be replaced. The GS-320 would hot-swap (semi-reliably) so it wasn't a HUGE deal, but it would slow it down and inevitably the build would be a day or two late.
Enter myself and a buddy of mine. First thing we discovered was that they were using regular java.lang.Strings for all the string manipulation, and it'd garbage collect for between 30 and 50 seconds every minute once the process got rolling. It used a positively criminal number of threads as well in our predecessor's desperate attempt to make it go faster. SO much time was spent swapping threads on CPUs and garbage collecting that almost no real work got done.
Enter the StringBuffer rotation scheme. John and I decided to use the backup GS-160 as a hub to read source data and distribute it among 16 of our floor's desktop machines as an experiment. The hub was written in C++ and did very little other than read a series of fixed-length records from a number of source files and package them up into payloads to ship over socket to the readers.
The readers gut-rehabbed the Java code and swapped out StringBuffer for String (and io for nio) to take the majority of garbage collection out of the picture.
The trick we employed was to pre-allocate a hoard of StringBuffers with a minimum storage size and put them in a checkin/checkout "repository" where the process could ask for N buffers (generally one per string column) and it'd get a bunch of randomly selected ones from the repo. They'd get used and checked back in dirty. Any buffer that was over a "terminal length" when it was checked in would be discarded and a new buffer would be added in its place.
We poked and prodded and when we were finally happy with it, we were down to one garbage collection every 10 minutes on each server. The final build was cut from 30 days to 2.8 and we got allocated a permanent "beowulf cluster" to run our database build.
My dad taught me to read with Dr Seuss and the TI-99/4A BASIC programming manual. Starting writing my first programs at 4. Love that old machine. There was a sort of Gradius knock off for it called Parsec that I played the hell out of too.
When I was a little older I would borrow books at the library to write games in BASIC. Basically key stuff in that the book told you to write, and since a lot of it was for the C64 or TRS-80 I had to figure out how to “port” it to the TI. I wrote notes for my changes in pencil in the library books so I wouldn’t get in trouble with the librarian. Invariably I’d check the book out again a few weeks after I’d returned it. I was probably the only person who read my notes, but I like to think someone got some use out of my addenda.
So let’s set aside for just a moment the notion of single payer healthcare as an answer to this. Why hasn’t a point of competitiveness between insurance companies ever been that they keep your workforce healthier, more productive, and easier to retain than the competition?
The biggest cost to an employer is always their roster. The fewer sick days people need, the less burnout causes them to churn, and the healthier and happier people are overall, the lower the training, recruiting, and redundant staffing cost.
It feels natural to me that in an employer paid healthcare system like the one we have in the us, the employer should demand the highest quality coverage possible by that metric as long as it reduces staffing overheads.
If you’re regular and become irregular, it’s often a sign that something is off, or if you’re into middle age, that your body’s hormone balance is changing. In either case it’s something to pay attention to and maybe mention to your doc next time you see them.
The thing is there are solid, replicable patterns for optimizing graphql. The way we use GraphQL is to expose "everything" to the frontend folks so they can work closely with design until they have a polished frontend for whatever they're building, then our backend folks look at it in APM in Datadog and figure out where to optimize it. Once we have an optimized query, we ship it. Everyone's aware of the basic optimization patterns we use, and backend is a pretty well-oiled machine.
I preordered Starlink in March of 2021, as soon as my first rural isp reneged on 50 megabits and sold me 5. 2 years later in western Virginia I still have no eta for my order and cannot contact anyone about it. I have 12 megabits from that same local ISP and it’s enough to do my job so I cancelled Starlink. I can’t imagine what customer service will be like if I am on preorder for two years and they refuse to give any update other than kicking the can down the road every time the estimated delivery date gets close. When I canceled my estimate was “early 2024”.
I mean they kind of say in there. It's an early emergent and it has broad leaves and grows dense mats, which inhibits native species from emerging. The native species are more suited to pollinators and other insects. They're also better at holding the soil together (so removing garlic mustard does in fact improve erosion control)
In my own exploration on my land, I've noticed that dead wood and leaves break down much slower where garlic mustard grows. This could be lack of insects or it could be something allopathic in the soil left by garlic mustard against fungal growth. In any case, the stuff is definitely detrimental to the land around it.
As for edibility the young greens are honestly some of my favorites. They work really well in spicy, meat heavy stir-fries and provide fresh greens at a time when there aren't a lot of fresh veggies about except for tough old kale and grocery store spinach.
Feels like a prime opportunity for a National Park. Restore it to the point where it won’t degrade further, add a museum, plantetarium, library, and preserve the land around the telescope. It’d be really neat! I’d take my kids to be sure.
I would love a game that melds witcher style open world "ronin" with a tactics-style game like Fire Emblem. Sort of a wandering knight in a broader war sort of thing. The tactics-style battles you join (or don't) and the way they go matter to the line of main and side-quests and the condition or existence of characters you'd meet along the way. A different way to implement the whole "choices matter" mechanic that you get from Witcher.
I might go to a town, fail to take a side in the battle that town is locked in, and when I come back the town is laid waste. The quests that would be available to me in town are no longer there, but I might have errands where I end up searching the woods for refugees instead.
Something like that'd have a lot of replay value, because what you do changes the game you're playing over time.
Teamworks | Multiple Senior and Principal engineering positions + an Engineering Manager position | REMOTE | Boston, Durham NC, Birmingham AL
About us: We are the operating system of elite athletics. We provide the software that supports your favorite sports teams, whether you're a fan of collegiate American sports, NFL, NHL, the NBA, New Zealand and Australian Rugby, or EPL football (and more!). We provide everything from messaging, calendar, forms, and compliance to nutrition management (via Notemeal) and branding (via INFLCR).
Responsibilities: depends on the position, but generally we're looking for people who want to flex between product and engineering.
I find ADHD to be an "occasional" disorder. I feel very much like the author much of the time, but honestly I want it to continue to be researched as a disorder, because I want strategies and medications that are better than post-it notes and Adderall (and yes, I've tried lots and no, none of them are better for me than the occasional 5mg of Adderall).
Most of the time, ADD works in my favor. But sometimes, (and NOT always due to "societal expectations") I need my brain to work differently than it does, and for those occasions the meds do wonders. But I truly hate the after-effects, thus I rarely take them.
This is absolutely correct. Neither chanterelles nor puffballs are "foolproof" mushrooms, even slightly. Mistaken puffballs are probably the number one cause of serious mushroom poisonings and even fatalities, since small puffballs look so much like amanita mushrooms that haven't fully opened yet.
And chanterelles have a number of at least moderately toxic lookalikes depending on the region you're in and how much an eager amateur is willing to stretch the definition. I don't think a lot of beginners can reliably tell the difference between "gills" and "folds."
Plus what you referred to about toxins leached from the tree that the mushroom was growing on. I'd not eat anything growing on a locust tree or a fallen rhododendron. Just seems like inviting trouble.
Neither is a bad option, but there's plenty of room in between. Series B, C, are often still pretty collegial, and you'll still get the opportunity to know the founders. The market's really gung-ho right now, and wherever you go you should interview them as much as they interview you. Pick something that feels good and will let you breathe. It could be really tempting to be ambitious right now and the main advice I would give you is "don't."
Don't try to make up for lost time. Don't try to prove anything. Don't make the next thing anything more than what it is: a job. Once you've rested and recuperated, and you can look back on your time at your startup and not "cringe" or feel angry, then decide whether you want to lean into the job you're at or move on and be ambitious somewhere else.
I've been a co-founder at something that felt like a "zombie startup." I walked away, gave up my entire stake in it back to the other co-founders, and washed my hands of it. It's doing fine now, and I'm fine with that. I saved myself the three or more years of pain, heartache, and panic attacks, and hopefully I gave them the breathing room they needed to get the thing off the ground. I will never see a dime of profit from it, even if it becomes a unicorn, and I'm completely fine with that.
The thing I think a lot of co-founders feel after a startup fails is a sense of "purposelessness," Burnout that manifests itself as a feeling that you're not "smart" anymore, not "creative" anymore. A blank space in your day fills itself with wondering if you could have made it work if you'd just done that one thing differently. You can't "power through" those feelings. You have to let yourself live with them until they pass over you. You have to let yourself heal, and healing takes time. Whatever job you take now should let you focus on that. It needs to be something that lets you spend some mental energy working through the regret, frustration, and ultimately the fear of facing your part in the failure of the startup.
Do the job instead of "be" the job. At least for a while. Take the time and get past all the things that will stop you from really learning from your experience. Then at the end of that, if you still feel the burn to start something again, you'll be able to put your whole self into it.
You can use SSH keys for VNC, too. Would be neat to see a PoC that allowed you to invite someone to remote control your computer temporarily via their github handle. https://ubuntuforums.org/showthread.php?t=383053
You know, I really should add a post soon about algorithms, papers, and textbooks. You make an important point which the first responder highlighted, "avoiding the destruction of business value by misapplying ML/statistics."
I understand the math behind what I do, but it's not a fair assumption to think that everyone reading my post will be motivated to pick up and understand the math before they start applying the tools.
Especially with tools like scikit-learn and orange, it's especially easy to misapply ML and statistics or simply approach a problem without understanding the tools and come out with something that looks plausible to the untrained eye.
Key to the reason that you should understand your tools, including the math that underlies them, is that you should be able to look at the results of your work and know if there's something "off". And beyond that the underlying understanding of the math involved gives you the tools you need to debug.
I knew I was forgetting packages. I do in fact use Tableau. Will add it. Thanks for the catch!
As for LaTeX, it would have never occurred to me to add it. I have no idea why not, but it doesn't. Maybe because it feels more like a chore than a tool. It's like an anti-tool. I mean, I do or did in the recent past use LaTeX, but in more recent years I would farm that out to someone junior to me who hadn't worked with it for long enough to prefer pouring bleach in their ears to being faced with tweaking one more broken LaTeX template.
I probably should include classical stats packages. They really should go in here. But I've been coding since I was a kid and typically eschewed classical stats and math packages because of my perception that they were slow walled-gardens, and that as soon as I had a method figured out in Matlab or SPSS I'd end up rewriting it in C, C++, or Java to make it work with other things or at scale. That was hammered home in the first company I worked with where we did modeling in SAS and then rewrote every model in Java because SAS couldn't keep up.
I'm not suggesting that classical stats packages aren't data scientists tools. I think they are. They're just not my tools because of the curious niche I found myself in.
I think it's great that students and young professors in the sciences are taught to code now. I've even taught some of them.
To me, data science is more than understanding statistics, it's been essential to know how to scale them up and out.
If you're a domain scientist, you won't necessarily learn how to write reusable tools that are performant (or runnable) on data that is different from your initial model data. I once worked with a group whose model had grown so unwieldy that their config file was in NetCDF.
I found my niche was often in doing things that were slightly (or completely) outside the comfort zone of most domain scientists who were competent coders themselves, but who didn't have the funded time nor the inclination to learn things like database, visualization, and networking technologies that became necessary either to share their work with other research groups or to operate on larger datasets.
One project had me take a big model that was normally run twice a day and on a 4km grid and help write something that could run and visualize the results of the same thing on a 0.5km grid over a larger area and hourly. And then devise something that could help them visually explore the timeseries as it evolved, sometimes over months.
Designing the pipeline that can handle that is outside the scope of most scientists, even the ones who are good coders.
Not all RESTful APIs will fit into a framework like this, and the choice of RethinkDB limits its applicability to a narrower community, but I intend on supporting other document-based DBs in the future. I really like RethinkDB's API and ReQL in particular, and it seems like a solid foundation to build something a little out of the ordinary on.
What makes it different from other ORMs? It's a rethinking of ORM mechanics for a "document-based" backend system.
* It tries to make the exposure of non-CRUD operations relate as a method to a logical server-side object and have a consistent endpoint syntax. It also uses Python function annotations to generate request and response schemas for methods.
All API endpoints exist within a four-tiered path hierarchy of
* Suite - base level, serves as a collection of applications and repo for basic shared schemas
* Application - a bundle of collections representing a logical set of functionality, methods that bind at this level act like "library functions"
* Collection - a collection of documents sharing a common schema. Methods that bind at this level act like "class methods"
* Document - a single instance of a document schema, representing concrete data. Methods that bind at this level act like "instance methods" in traditional OO programming.
What helper features does it have?
* Reusable apps / collections.
* JWT based sample authentication app, auth.
* Automatically generated help from schema descriptions and python docstrings
* Self-describing schema endpoints for suites, applications, collections, documents, and their methods.
This is pre-release stuff, to be sure. I'm using it on personal projects, but it needs:
* More tests
* More docs for the Python side of things (I'm working on this first)
The solution usually isn't "better people." It's engaging people on the same goals and making sure each of them knows how their part fits with the others. It's also recognizing when hard stuff is worth doing. Yeah you've got a module with 15 years of tech debt that you didn't create, and no-one on the team is confident in touching anymore. Unlike acne, it won't get better if you don't pick at it. Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.