Hell no. Why"? Should a anesthetist do he work of a surgeon? It's insane how this industry brainwashed people into becoming jack of all trades, master of none.
There's a difference between becoming incredibly good at frontend and knowing enough to get things done and be a productive member of a team (ie, not get fired like the OP).
I know "some front end". Some things I have picked up like I always knew them, some things required study, some things I'm not going to be good at, and at this point, I'm old enough to know the difference.
"I don't do X type of work" is pretty unrealistic and comes across as more stubborn than anything else. This is especially true in a small/scrappy company up to medium size companies where you're expected to wear multiple hats.
Maybe at Google you can get away with being the "person that does X-only" but that doesn't work in most companies.
Your job is to do _the thing_ if that thing includes front end work, then you do the front end work.
If you negotiate it before being hired, and you get hired, it's a real stupid move for managers to expect you to do the job that you explicitly made it clear you don't want to do / can't do. It's so easy to not hire someone, I really don't understand hiring people who hate and are not good at the job you want them to do.
The recent example was a large, international company. I mentioned this in the post.
> Your job is to do _the thing_
Like I said in the post, I do what I get paid to do, and the idea is to figure out how to avoid a place where "the thing" is inappropriate. I have an easier time at startups: I'd rather spend 12 hours a day doing something that matches my talent and interests than spend 8 hours a day saying "Yeah, the button is...I don't know why it is where it is. It looked fine to me before, I don't wanna spend two days on this."
It depends on your threat model. If your threat includes three letter agencies and nation states then you're right-- don't use Proton. However, 99.9% of people don't have that threat model. In that case, Proton is better than most other providers out there (for email, vpn, etc).
I would hazard to say if that's your threat model, you're better off not using the internet in general. VPN provider won't really matter ultimately, there's a hundred things on either side of that tunnel that you have to take care of.
I'd argue physical channels and access are even less secure. People are broken easily (you can't trust anyone) and surveillance is everywhere and more sophisticated than you imagine. My first job was at a US-based video surveillance company owned by Israelis and used by casinos, stadiums, and entire cities. I have an idea of what it's capable of :)
What we need is a truly secure and private method of communication and payment. We're close on both.
The methodology is simple enough, the issue is the devices.
Sure you can run hardened, stateless linux, but how many SOC's are in your laptop? Those aren't trustable. Your phone's even worse.
Sure meatspace is full of surveillance gear, and has been for years. Face rec/id has been around for a decade longer than people think, plate readers, traffic cams basically everywhere, etc etc. The problem those systems all have is filtering out the signal from the noise. They don't know that person-X is someone to watch until they're tagged. Once they're tagged, it's basically over, but, how do you tag them? Right now, that's mostly manual, and based on external data. If there is no external data, there's no risk of being tagged.
The real question is, can someone remain normal enough while not generating suspicion while they're up to no good. I'd say they certainly can, most don't, but, it's far from an impossibility.
Also, the comments on the Kickstarter page [0] make for an interesting, if sad, read.
Linked on [1] is where he comes out of the woods again, the following comments and his replies also shed some lights on what he feels he is owing the people, that pledged $185000 on Kickstarter....
Honestly, anyone who says they’ll be creating an engine and sharing it for general use, is someone who’ll likely never make a game themselves.
It’s definitely possible, but incredibly difficult to make something generic out Of the gate.
Unfortunately, it’s all too common among indie dev projects seeking backing, because it sounds like a cooler idea and people seem to like the purity of the idea.
Pretty much true. Not only that, but if you look at the Kickstarter page, what exactly was my job? Engine programmer. Not gameplay. Th engine is pretty much complete, as are all of the tools. Problem is it taxed me so hard and left me with so little extra time and cognitive resources that I could not properly lead the rest of the project or the team-mates whose job it was to do the gameplay aspect... Which is absolutely a leadership failure on my part, and I'll happily own up to that.
It’s classic scope creep. They should’ve released the game as a base and made the engine and tools kickstarter bonus goals to be delivered later. They should’ve also constrained the scope to “2.5D top-down action RPG engine”. What happened in practice was that they went on constant tangents like writing emulators for the memory card. I can imagine that a lot of team drama came from this mismanagement impeding progress and making everyone’s job harder.
I do totally agree that I should've just made an engine and the toolkit and just released it as that, but it wouldn't have been "THEY should've constrainted the scope" -- as there would've been no "they." It would've been all me without a team I had to support by splitting that Kickstarter so many ways that we made under minimum wage in the end... lol.
Falco, I have watched your DC work since you first started on YouTube. When I say „they“ it is out of politeness to not name you directly and also because I think some of the blame lies with others. I used to be a well-known member of the DC community and defended you for years. I had a lot of respect for your efforts. I am however embarrassed to have defended you not because you failed, but because of how you handled the failure even to this day.
I was king of scope creep, but I was also the engine and tools developer... Does it LOOK LIKE the engine and tools were the ones bottlenecking progress, or does it look like a lack of ACTUAL GAME CONTENT was the problem with Elysian Shadows? The engine and tools (which were my job) are probably easily at 90% done.
What I do own up to is being so bogged down with coding up a whole cross-platform engine and toolkit that I was an absolutely horrible manager who just relied on the rest of the team to know what needed to get done and take care of it, which obviously never actually happened. I was not as involved in the rest of the actual game aspect of ES independent of the tech than I should've been, and I own up to that...
But if you actually think THAT is what caused this game to never get done, you aren't seeing clearly. That's the one aspect of the game (other than audio, which was never a problem) which was actually where it should've been in terms of progress.
Also, for the record, LOL, ElysianVMU caused "drama" and extra work for the team? Funny, not one person other than me wrote a line of code for EVMU or even implemented the single line of Lua code it takes to display a VMU icon in-game... and as far as I ever knew, Patryk enjoyed getting to take a few hours to get away from killing himself being overworked on terrain and character assets to get to draw VMU icons, or so I'm assuming based on the fact half of what he drew were penises and jokes, initially. ;)
Also, for the record, LOL, ElysianVMU caused "drama" and extra work for the team?
The constant tangents did, that project being one of them. The VMU emulator did not kill anybody’s firstborn, but like the other many tangents it ate away at your time, which was required elsewhere.
I see you haven’t changed and still try to misinterpret people’s comments rather than really owning up to the past.
It would seem the best way to put an end to the ES fiasco is to simply release what you have (and post the update to Kickstarter)?
If the engine and tools are 90% complete, it's better to release 90% of something than nothing at all. The backers would no longer be able to call it a scam. It's probably the only way to put it all to rest.
Uh, for the record, like... I've been more than open about my past history with ES, and have spent the last 2+ years straight giving back to the Dreamcast community, supporting every game and project I've been able to find time for, fixing many bugs that have plagued this scene for decades and becoming the developer with the second-most commits to the KallistiOS repo in just 2 years, beaten only by the lead maintainer with over a decade of work...
But yes, way to take the spotlight away from the developers who are pouring their hearts and souls into this project, of which I'm only an insignificant part of, to bring up some irrelevant shit from my past which I have owned up to and am literally working to correct by supporting projects like this... total douche bag move. Makes me feel sorry for the rest of the team, tbh.
Given the various accidental leaks dues to people not realising deletion still has a history with git when publishing (not to mention git has no equivalent to mercurial's "censor" operation), or people confusing public and private repos on their github accounts, or even the story just last week here on HN with counterintuitive behaviour of forking in terms of privacy (https://news.ycombinator.com/item?id=41060102), I can totally understand a company being opposed to being on github.
Might be a relatively easy sell if you just setup a local migration of their data to repository with a decent web gui for viewing the commits and associating with tickets, given my experiences with TFS in terms of slowness, and crashes/data corruption.
> not to mention git has no equivalent to mercurial's "censor" operation
Haven't followed that for a while, but it used to be the case that it was Mercurial who was principled/fanatic about never rewriting history, ever, while git happily let you mess up with hard deletes.
Which is still the case. They use the hidden phase to avoid that. You can use hg absorb (also awesome) locally of course to simplify matters.
What censor is for is the case where something absolutely has to be removed from the repo, for legal or security. It allows you to do it in a clean standard way, even replacing it with, say, a key signed statement, without forcing regeneration of the whole repository or altering the tree in any way.
... and gotta say. mercurial will let you do hard deletes. They just discourage it and try to offer tooling that allows you to do what you want without destroying history / changing hashes / generally complicating life for those using the repo.
They also do have the tools to completely rewrite history if you really really want to.
So, "principled fanatic" is not quite accurate I feel. They just have a lot more options than git (which also applies to their commandline tooling I feel, although of course there's a lot of 3rd party stuff out there for git to mimic much of what mercurial has out of the box these days).
Here’s a few of my horror stories where I was a consultant at various companies:
1. Previous consultants left no documentation or anything, and a running Hadoop cluster handling (live!) 300 credit card transactions a second. Management hired 8 junior sysadmins - who were all windows sysadmins, had never used Linux before, and were expected to take over running this Linux cluster immediately. They all looked at me white as ghosts when I brought up SSH prompt, that’s the point where I learned they were all windows sysadmins.
2. Another company: all Java and MySQL developers who were trying to use Spark on Hadoop, refusing to learn anything new they ended up coding a Java app that sat on a single node, with a mysql database on the same node, that “shelled out” to a single trivial hello-world type function running in spark, then did the rest of the computation in Java on the single node, management celebrated a huge success of their team now using “modern cluster computing” even though the 20 node cluster did basically nothing and was 99.99% idle. (And burning huge $ a month)
3. Another company: setup a cluster then was so desperate to use the cluster for everything installed monitoring on the cluster, so when the cluster went down, monitoring and all observability went down too
4. A Cassandra cluster run by junior sys-admins and queried by junior data scientists had this funny arms race where the data scientists did what was effectively “select * from *” for every query and the sysadmins noticing the cluster was slow, kept adding more nodes, rather than talk to each other things just oscillated back and forwards with costs spiralling out of control as more and more nodes were deployed
Any many more!
This might sound like I’m ragging on juniors a bit but that’s definitely not the case - most of these problems were caused by bad management being cheap and throwing these poor kids into the deep end with no guidance. I did my best to upskill them rapidly and I’m still friends with many of them today, even though it’s nearly 10 years later now,
"Senior" holds no weight with me. I've had plenty dumb founding conversations with "seniors".
My favorite was at the company that was self hosting their code. The senior team lead wanted me to help him find a memory leak that plagued the product for months. Customers were told to restart the application every few weeks (this was a C++ application).
I sat down with the senior and looked at the code. I spotted the error.
I was like, "You know when you do new[] you need to use delete[]?" as all of his deletions were without [].
> I was like, "You know when you do new[] you need to use delete[]?" as all of his deletions were without [].
This seems like a pretty major lack of a specific piece of knowledge on the senior developers part, yes, but it seems like a much more unforgivable miss on the part of the code reviewers. Was the team stuck in a rut where only a single person (with coincidentally the same blind spot) was reviewing his code, or did multiple reviewers somehow miss this?
I've worked with a consultancy that prouded itself by exclusively hiring top engineers from top universities and I swear, I can put my hand in boiling hot oil and tell you, they were some of the worst coders I've ever seen, I have no doubts I've met way more brilliant people coming from boot camps.
The fact that people study for exams has absolutely no correlation with how much they will remember or care for what they studied, none.
Titles really mean very little. The company I work at recently hired a DevOps specialist to help configure Docker services and assist with development. He was a decent developer but had no idea how to securely configure server side services. Still stuck with his mess two years later :)
…but it is also imperative to remember any modification on checked out code is a branch, technically, regardless of the version control system used. This becomes important if your testing is expensive.
I live near Intel HQ and I know many Intel employees. Everyone I know has been interviewing at other companies for the last 8-12 months. I haven't met a single person that had a positive thing to say about Intel and its future.
Paul Otellini and Brian Krzanich (both from sales background) have made such strategic mistakes its hard to overstate, combined with the govt office work culture makes it not a great place to work
