ninjapenguin54
Location: Chattanooga, TN
Remote: Yes
Willing to relocate: Yes, with relocation assistance.
Technologies: React, Python, Django, Node, Typescript, Postgres, C#
LinkedIn: https://www.linkedin.com/in/charles-taylor-349609133/
GitHub: https://github.com/CharlesTaylor7
Email: My first and last name can be seen from Github and LinkedIn. As a python formatted string: f"{first_name}{last_name}[email protected]"
Resume: please email me if you'd like a PDF version of my resume. It's basically the same as my LinkedIn profile.
I'm a big fan of statically typed languages, and automatic testing, (both unit and e2e).
I have professional experience in the above listed technologies, but I am also to keen to begin working professionally with Rust. I generally default to building my side projects in rust these days.
Isn't this just a performance optimization?
I take the original statement to mean that worse case scenario is extra time to load.
The idea that empty string and none are equivalent is distasteful.
Nobody makes this argument for int fields right? "Just use 0"?
I hate having different conventions for different field types and losing a potentially meaningful distinction between empty string and 0.
The idea seems to be born out of truthy & falsey values. (A big source of gotchas and bugs in my experience)
I'd say it's the role of django forms to clean data into a normalized form. So converting null to empty string there might make sense.
tl;dr an attempt was made and failed. Turns out there's not enough incentive for websites to convert to your stricter html replacement.
Energy does have a conservation law. Entropy does not. Not does information, complexity etc.
I majored in phyiscs, I'm familiar with these terms.
Grand parent post made no indication they were talking about essential complexity when they made their bold assertion about how it's conserved like energy.
I'm also not aware of any formal or precise way of measuring "essential complexity". Not in the way we do for energy or entropy.
Heres an amusing and simple example of manufactured complexity: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Take homes can & ought to be timed.
I've had the opportunity to do this fornat twice and I think it works well.
Here's how it works: They ask you to pick a 3 hour time window to work on the project. You pick the time. They send you the project prompt in an email right at the beginning of your time interval. You have 3 hours to read the prompt, design, implement, test a solution. If you miss the deadline, project counts for nothing.
Both the times I did this the prompts were absolutely doable in 3 hours. They were the kind thing you could do in about 2 hours if you had the ability to read the project prompt ahead of time and think about it for a few days.
Personally, I work well with time constraints. This format feels closer to a workday where mid-afternoon you might challenge yourself to finish a task before 5pm. Its a lot less pressure than having to juggle a conversation and having your code scrutinized in real time.
It forces a real time constraint that keeps you from piling time into something you just don't know.
Its hard to cheat, and it also forces the company to make the task achievable in the time frame. This format forces them to realize when the task is too big for anyone to finish in the time.
I tend to think of git as tool to aid organization and not an opportunity to flex my prowess at mental gymnastics. Crazy, I know.
Don't blame the language, & learn to use the right data structure for the job.