Now, let me be completely straight and honest, if you need exercises in react, react won't be your career.
Do you know how reactive stuff are implemented in js? Do you know how those are implemented in C?
Can you implement them yourself in both js and C?
If you can do it, a component like a calculator is trivial and you just need to adjust the syntax and jargon.
If you can't, this exercises will just be exercises in memorization and shallow understanding.
What I am saying is to learn how to implement the underneath engine in low level languages, it is much more fun and productive.
Anyhow, your life, your time! After all I am just a stranger on the internet.
What you said makes sense, but only to limited set of people.
Not all people are interested/capable of learning how it works underneath. There're like, I don't know, hundreds of thousands of React developers in the world, very few of them understand how React really works underneath.
This is actually one of the goals that React was invented and popularized inside Facebook. It's just sooo easy to pick up and start building.
That being said, for our product, it's not only about React and its basics. We can totally create a workout project for React internals. That depends on what you guys need :) We started with these two projects because it seems a common useful and popular thing, and we're able to do them ourselves.
Thinkpad X-series is the alternative with a more durable build and a comparable pointing device. I would recommend any Thinkpad, but the X series is absolutely fantastic.
Pasteurization destroys some vitamins. Also, supermarket milk goes through more than just pasteurization: some protein and fat is removed to make other milk products like butter and cheese.
I'm the sole developer working on my current project, which is overhauling a massive DOS era application, as well as overhauling an early 2000s era CRM/business management tool, that almost all of our work happens through.
Did I mention that the DOS application is a HIPAA billing application that must meet all HIPAA guidelines as well as write EDI X12 billing files?
I'm very junior, been coding for ~5 years, 3 professionally, but this is my first real dumpster fire. We were about to hire a second developer, but turns out he had a record. Not for just anything, which we don't really worry about, but for embezzlement on the healthcare billing application he used to own. So, no. No can do.
So now poor 18-year-old me is knee-deep in a ton of shit I don't understand, working on non-version-controlled code, having been expressly forbidden from using ANY VC by the CEO, and trying to get details out of my older supervisor who built the code we're using, but he's near retirement and has so many vacation days saved up that he spends maybe 10 days a month in the office. I honestly can't blame him, but I either need resources to help me deal with legacy code, or a nice entry-level rails job, because I want to finish learning rails.
>having been expressly forbidden from using ANY VC by the CEO
Well that's really fucking stupid of them. Maybe they're worried about evidence of old HIPAA breaches existing after the system gets updated, and doesn't want to explain that logic? On your local development station:
mkdir repo
cd repo
git init --bare
cd ..
git clone repo project_folder
cd project_folder
cp -r ../<path_to_project>/project project
Congratulations, you now have version control for local development that your CEO never has to know about! The only reason I'd suggest an extra folder (horribly named project_folder in the example above) is so that you never accidentally copy the hidden .git files when moving it from your dev station.
Wow thank you so much for this. There's some stuff I've been working on which I want to sync to Dropbox as I type but without the .git being synced too. Up until now I've just had to deal with the .git files being synced with Dropbox. But now it looks like I finally have a way of moving the repo!
This was my first exposure to a professional development job, but for medical transcription (we had a billing dept too). I wasn't even hired to do it (I was hired as help desk staff), but the application neeeeded updating and the 2013 HIPAA omnibus had just dropped so we were on the line to get in compliance and no one else was stepping up. I had to learn as I went. decade old, undocumented code written in old .NET and (some) Java 6.
No version control, running on Win2000/XP, ancient beige box hardware (some with turbo buttons).
I was 19 and making $9 an hour. I got fired for automating my help desk tasks so I could bring us up to date.
Yeah...as someone who works on HIPAA compliant software, this sounds very scary to me. We carry a $1M insurance policy at all times. Did you sign a business associate agreement?
Not just jail, you are also now personally liable. Meaning your personal assets are on the table for a lawsuit (at least according to Stanford’s HIPAA training)
You won’t go to jail if you do nothing wrong, but legal fees. Ugh, yeah, you’ll be in court as a witness and possibly defendant if you don’t leave ASAP.
Well that would be the OCR. It’s doubtful they would waste a lot of resources going after a developer, unless they really thought he had done something. Usually they go after leadership.
not a lawyer, but I think intent is a big piece. That said, if you ever feel pressured to do something that you know, or even think, might "not be quite right", diplomatically argue your point and get things in writing. Even an email thread between you and a manager is good. The idea is this: if the fecal matter hits the oscillator and auditors come in, you want evidence that you were doing what you were told, despite your protests.
Unless you're boss tells you to do something so egregious that after the fact it will look like you're stealing or committing fraud you'll be fine.
If your boss says "Hey download all of the PHI for these celebrities to a flash drive and load it on your computer at home" you should definitely say no or get it in writing.
But if your boss says "hey I need a copy of George's medical records, e-mail them to me" as an individual you won't get in any personal liability for it.
I worked in insurance for over five years (at a Fortune 500 company). I had annual HIPAA training. I was in claims, so I'm not sure how pertinent this will be to your needs, but here is some stuff I remember:
1. HIPAA has a minimum necessary standard of disclosure, which means give only however much info you must give to accomplish the task in question.
2. You need at least three pieces of identifying info to positively ID an account, such as name, address and account number. (Other possibilities include: Social security number; date of birth; phone number.)
3. When disposing of papers or other media containing covered information, it must be destroyed, not merely thrown out. This means papers, floppy disks, etc must be shredded.
4. If you're printing a lot of papers with HIPAA covered info, you should have a locked trash can for any papers you are discarding. Presumably, this is merely a holding bin until it gets shredded.
5. Papers with pertinent info should be turned face down if anyone comes to your cubicle to talk, even a coworker. Ditto for papers coming off the printer containing covered info.
6. You need an annual HIPAA training program to remind everyone of a lot of the above (and likely other things I'm not covering).
7. Computers should be password protected when you walk away from your computer.
I guess the short version is: When in doubt, err on the side of making sure the information cannot be accessed by anyone who isn't using it to accomplish the purpose it is intended to serve. Also, you can't go flipping through covered info for funsies. Although you have authorized access, it's only authorized for a specific purpose.
> 6. You need an annual HIPAA training program to remind everyone of a lot of the above
When you say 'need' do you mean 'legally required to' ? I wonder if that could work to the advantage of the poster, in that if they left because they became aware that things are not being done correctly and they have never had any such training, the legal responsibility would reflect back on the employers who had not provided such training to an obviously inexperienced employee and the CEO in particular who is the person who should have known to do that.
I am not in the USA and I think the UK has slightly better employee protections and lines of legal responsibility, at least in some areas (such as Health & Safety) but who knows..
HIPAA requires organizations to provide training for all employees, new workforce members, and periodic refresher training. The definition of “periodic” is not defined and can be left open to interpretation. However, most organizations train all employees on HIPAA annually. This is considered to be a best practice.
I worked for a "CTO" who didn't allow us to use version control either. This was from 2007-2010. I am surprised there is a company TODAY that does this, but I guess I shouldn't be.
The reasoning behind not using VC was that it "caused more problems than it solved." His solution? Code directly on the production server. Yep. You heard me right. Let me say that one more time. Code directly on the production server. We eventually finally won a development server and wrote some bash scripts to deploy from there, but we never actually got SVN or anything. Imagine working on five person development team with no version control.
The guy was a serious joke. The VC issue is just one of many. A serious despot. The guy was hated by all. We laughed at him. Why would I stick that out for three years? I had zero experience when hired. All of us were very green. We were all just putting in our time to hit that magic three years experience checkbox we needed for the next level gig. The CTO was more concerned with appearing to have a large department and having developers working on lots of different things, than actual quality. We wrote some pretty terrible code back in those days and we did a lot of it on a production server during business hours.
We all left at or around the three-year mark. Month by month the "CTO" lost developers faster than he could replace them. The "CTO" was eventually fired and we laughed from afar.
You are being taken advantage of like I was when I first started. You are cheap labor. Your CEO doesn't care about the product. Your CEO likely doesn't care about your career development. The sooner you leave, the more you will learn and grow. That was my experience.
> Code directly on the production server. Yep. You heard me right. Let me say that one more time. Code directly on the production server.
What a coincidence! We have a customer that is having a strange, hard-to-nail-down problem with our software. We asked if we could provide a diagnostic build to them that they could run in their test environment to gather additional information about what was happening.
Their reply was that they didn't have a test environment. They just install any software they get directly to their production machines.
The good news is that there are fantastically good shops to work for (you should start looking for one), and that you'll have some good stories to tell about the hellmouth that was your first company.
If they require that you don't use version control but at the same time want it to be HIPAA compliant you need to walk right now if you have options, ASAP if you don't. You're being set up to be blamed if anything goes wrong.
Change management is part and parcel of anything in the medical software domain, and VC is an obvious part of that.
The CEO has likely given this directive to avoid a paper trail. Any attempt at rationalizing with the CEO will be a waste of effort when this person could (and should) be focused on finding another place of employment.
This is bad advice. If you accidentally leave personally identifiable healthcare information on some random stage server and that server gets hacked, that is a federal crime. If the data and application code are very intertwined (likely in a pre-SOA era), it can be very difficult to version control code completely isolated from PII.
> If you accidentally leave personally identifiable healthcare information on some random stage server and that server gets hacked, that is a federal crime.
Not sure how that relates to Version Control? I personally don't put production (real) data on staging servers to begin with; always scrub your production clones or generate data for testing instances.
> If the data and application code are very intertwined (likely in a pre-SOA era), it can be very difficult to version control code completely isolated from PII.
Maybe I am naive (never had to work on DOS), but shouldn't the data be in a database/datastore/data directory that can be ignored by source control?
Apparently (according to a carpenter friend) - if the carpenter uses a hammer on a modern build it means something has gone wrong - they're normally using nailguns or similar to put things together - hammers are to bash them back apart again or knock them into alignment if they weren't done right the first time.
Hammers can also be used in awkward to reach places that a nail gun can't get to. Also, structural timber is very rarely straight or true. Knocking things into alignment is a very common part of framing, and hammers can achieve sub-millimetre accuracy with gentle tapping.
Yes, nail guns are awesome, but hammers are very useful tools.
I've done some work as a builders labourer. Admittedly ~18 years ago.
Nail Guns are awesome. Pneumatic, butane/battery and powder actuated all have their place and were heavily used. Always had a hammer on my belt though.
In particular, it's hard to use a nail gun to fasten a plate, hanger or bracket.
LOL, yes nail guns are the more efficient tool these days, however I bet these carpenters still have a hammer on their tool belt and use it at least once a day.
If you're that young (18??), you can almost definitely afford to quit tomorrow and look for something better.
Never sacrifice your own career for your employer's success (within some time horizon.) Being willing to quit when your boss is a clear bad actor is a core part of this.
It's hard when you're young (no savings, car payment, whatever).. but it gets harder before it gets easier.
This is a time in your life when you're (hopefully) not supporting anyone else, don't have a ton of possessions, don't have a mortgage, can couch-surf, eat ramen, etc.
Same boat, similar level of responsibility and I’ve been programming 20 odd years.
I accepted an offer yesterday, 35% pay bump, 5 extra holiday days, twice the bonus cap and all of that pales against knowing I’ll never have to touch that fucking codebase under unrealistic constraints again in a short time.
In stead I get to run a team, in a much bigger company with proper modern development practices.
When they rang to tell me it was mine if wanted it I was literally shaking, it felt like an elephant had stepped of my chest.
Until that point it really hadn’t occurred to me how unhappy the last two years at work have been, fighting the worst undocumented codebase I’ve seen two decades was a long slog, doing it alone for people who don’t understand the issues just made it worse.
Will be putting my notice in next week.
As someone 20 years older than you, get out and get out soon.
You are damaging your future career chances by stagnating in a job that won’t teach you how to do things better for your future.
I'm bewildered as to why a CEO would have any opinion on version control at all. Or why you'd ask a CEO whether you could use one. It's like a builder asking a construction company CEO if he can hold a hammer lower in his hand and that CEO forbidding it. Can someone explain?
A good friend of mine worked for a small company whose CEO also tried hard to convince him that introducing version control was wrong.
Of course, this same CEO also didn't see any problem with the fact that the password field in the login form was never checked against the database, because who would know someone else's login name?
I'm not exactly at a fortune 500. I'm one of two developers at my company and it would be hilarious to me if my CEO (who seems like a nice enough guy) even knew what version control was.
Small company, maybe a dozen people total, only tech-adjacent, not a strictly tech company. The CEO (which, for a company this size, probably also meant owner and perhaps sole board member) and maybe a fee other people at most had built the site in question.
The dev says himself that he is a junior, and it is very likely that the CEO of a tech firm has more than junior-level experience in technical matters. Even if he doesn't, it is still fine for a junior to ask his superiors for advice.
- Hey Joe CEO, which version control do you think I should use?
- None, that's an order!
It was a small (tech-adjacent, not strictly tech) company, and if memory serves right the owner built some of the site in question himself. I dont know that my friend reported directly to anyone inbetween, at least not when it came to technical matters anyway.
Listen. If not using version control is a problem for you, you're already more hirable than a lot of developers I've seen. Learning is always important but don't use that to procrastinate.
You don't have to go straight to the best job in the world. Just find something better (and do your homework to verify) and take it.
I'm in a small city, where not much work is available. I need to pad my resume a little more to make the work I do more attractive, but the reality is that LAMP devs aren't in high demand near me. I apply to several jobs daily, but not much is around. I'd appreciate pointers on how to improve my prospects, but the last place I interviewed was a seedy adult entertainment company, and I wouldn't have taken an offer if they begged, simply for personal reasons.
You said you're 18, you're young and hopefully don't have kids, so apply in other cities as well.
Yeah it's scary. But if the job is good enough, and the pay is good enough, then you've got to figure out why your bullshit reason for staying where you are outweighs both your mental health and your career prospects.
God, at 18—or hell, at 22—showing the fuck up and not seeming entirely incompetent is a big deal. Show up, be engaged, do both consistently, and anyone who's not a total piece of crap will be all over giving you more responsibility and mentoring you up to bigger and better things. Total pieces of crap may still be interested, but it'll be in exploiting you (as in current situation). Oh, and ask questions. No one expects you to know diddly-squat, so ask away. Ask about stuff that's not part of your job description at all. People will tell you all kinds of stuff, and, incredibly, the whole exchange will make them like you more.
Phenomenally small amounts of give-a-shit go a long way for youngsters. It's basically their superpower, if they're willing and able to use it.
I know a bunch of remote-hiring places and if nothing else I'd be happy to help you figure out what to learn (and, probably, how to approach it) to GTFO. Email is in my profile.
Leave the city. It doesn’t end well if you stay... unless you can get remote work (even then it’s risky), but you definitely have to leave the company ASAP
> I need to pad my resume a little more to make the work I do more attractive
A word of caution: One of my objectives as an interviewer is to drill into a candiate's resume to see if they actually did what they said they did. Its OK to talk up your accomplishments. But don't claim expertise in language X or technology Y unless you are prepared to answer some questions about it.
I interviewed a guy who's masters work was in the field I did my doctoral work in. I think I'm the only one in the company who knows anything about the particular topic, and considering that the role was far removed from that topic, it was a very unlikely coincidence. However, when discussing his research, he mostly missed the mark. It wasn't enough to sink his application as at the masters level I wouldn't expect him to know it nearly as well as I do, and he was ultimately hired. But, you never know who you're talking to.
But this conversation has been about them saying they need to learn more before they can get a new job, and me replying that they shouldn't use that as an excuse to procrastinate. Thus the `need to pad my resume` comment.
Magento shops are always looking for LAMP devs. A national recruiter told me they place PHP devs at the big Magento shops without the job ever existing.... There must be a Magento agency in your city?
> having been expressly forbidden from using ANY VC by the CEO
You can run a local git repo, no code would ever leave your PC. I'd do taht, and damn the torpedoes. If he is dumb enough to say no versioning, he'll never know you run it locally.
I was sort of in a similar situation when I was your age - in over my head at a complex project where the owner had never heard of version control (though in my case, I was too green to realize that it even existed). They had 30 copies of the same software, one in a folder on a shared hard drive for each customer. If there was a bug and it wasn't specific to a customer, you had to go fix it in 30 different places.
I promise you, if they don't want to provide version control they aren't going to provide you with other benefits and necessities that you deserve.
Related questions to benefits and necessities:
* Are you getting healthcare?
* How is your pay compared to other Jr. software engineers in your area?
* Are they paying you hourly? If so, are they actually paying you for hours worked, or are they finding ways to reduce that number of hours?
* What if you demanded that they used version control, and brought your best arguments: what would they say?
Consider the answers to those questions, and if you don't like the answers, I strongly urge you to leave. There's a complacency that can come with "settling" for a place that is a "known constant." Don't settle here, when you deserve more.
Put what you've done on a resume, and give it to a headhunter. They will find you a better job - maybe not an ideal job, but a step up. And your career will truly begin.
Ghost this job immediately. It's a clusterfuck waiting to happen, and your bosses are going to leave you holding the bag when everything turns to shit.
You're a programmer, not a fall guy. You aren't getting paid enough for this.
You are 18 and been working professionally for 3 years. Well done. All said and done this is what matters. Real life experience over university education.
One thing for GP to consider: I did the exact same thing (worked for three years in software development), but now I’m back at school in college. This obviously depends on if you think school is worth it (I did), but I wouldn’t be surprised if my work experience before college helped me stand out in the application process.
Either way, good luck!
> What's are the arguments against version control here (if any)?
* I don't understand it
* You're overcomplicating things
* We're not using any of that free shit here
* It doesn't say Microsoft or IBM
* The last guy we hired that tried to use it was smarter than I was so anyone else who tries is a threat to my leadership. (because everyone knows you can only manage people who have a strict subset of your own knowledge. If one of your peons dared learn something before you, that would be the end of your reign.)
I've got these responses on a similar question: "we don't need to see the commit logs so who cares about them or the history being pretty and clear? Nobody is looking at the history!"!!
The question was "Let's submit pull requests as a clean job not as a homework draft. Why don't we allow push force on work branches so that we can squash fixup commits after review?"
Blows my mind that those are senior developers that are otherwise seemingly competent at what they do. There is some pinch of job security there though.
There are valid reasons for a "never rewrite history" policy, but their validity pales further you go from the master branch.
The thing is that in a lot of scenarios people need to do huge chunks of work in feature branches. Sometimes a 3000 line "refactor the world" squashed commit is really unhelpful. The best policy is always well thought of weighted case-by-case decisions.
However, on projects with a lot of hands on the keyboard such policy is unrealistic and someone will do the opposite of what they should and wont ask or discuss. People, especially in our business, hide incompetence behind aloofness and silence.
So in that case, with a lot of people that are hard to manage, stiff policy is the best choice and there probably are reasons why people want to preserve history, no matter how hairy it looks, at least it's there and you can find stuff in it.
If you can't trust your employees to adhere to HIPAA or other mandatory regulations, you need better employees.
If your source code contains personal information, usernames, passwords, etc that should not be exposed to the public, you need to address that immediately regardless of any irrational stances on version control.
> "If you can't trust your employees to adhere to HIPAA or other mandatory regulations, you need better employees."
You need a better process. Developers aren't lawyers. Of course they should be aware of HIPAA requirements, but better is to ensure they simply don't have access to sensitive production data except in very controlled circumstances, while making safe anonymised test data available for anything they need test data for.
* It didn't exist at the time, but there was an on-prem that MS offered a few years back. It was forced on another department with no version control experience. It lasted about two weeks.
I've learned there are arguments that are not worth winning, and if you find yourself in one, your priority should be getting out of the situation that created the argument.
I'm not sure what the answer is for version control, but I refuse to accept it's Git. I don't understand how it became so popular - did nobody say "wait, there might be a reason why Linus is known for cloning an OS and not coming up with a brilliant design for one from scratch?"
Git is great. Lightweight, scales effortlessly, learning curve isn’t too bad, decentralised by design and because it’s so widely adopted it works pretty much everywhere.
The learning curve isn't too bad? Do you actually use Git? Like, from the command line?
I have no issue with a friendly wrapper in general, but after starting with the basic interface, I don't trust a wrapper to be logical, complete, and well thought out, given the foundation.
Yes, I use Git mainly from the command line and I've used it on Linux, OSX and Windows. I've also used quite a few GUIs including SourceTree, Github Desktop and GitKraken. I've been using it for a while now!
In the end it really boils down to a few commands that you use often, checkout/push/pull/commit/clone/branch/diff/status etc. It can definitely get confusing at times when you get merge conflicts and want to start playing with rebasing and stuff like that.
I've used it with teams with no experience with Git whatsoever and they're usually fluent at the basics within a week or so.
If you get stuck the command you need is usually a 2 minute Google away.
Git follows in spirit the model of BitKeeper, a software that already worked exceptionally well for Linus and other kernel devs. So Git had both a known good design from the very beginning and a decently sized installed user base (kernel devs) with an important project (the kernel).
IMO there's nothing wrong with the cloning of software. You make it sound bad, can you give reasons?
I honestly enjoy the work when I know what's going on. We have a lot of unique problems to solve, and I have gotten positive changes made, as well as some really good weeks where I pounded out some good code, but other times it's slow, sad, and frustrating.
Like others have suggested, use git locally, there's no need for them to be involved or aware of that detail. Do you consult them on what text editor to use?
There's a skill to learn in keeping engineering concerns to yourself. It's unsurprising when management or executives are faced with decisions in unfamiliar topics they err on the side of Nay. Your mistake is involving them at all.
Using git locally is a tool just like your code editor. There's no need to ask your boss about that.
Since you're the only developer it's mainly to make it easy to revert any mistakes and to have confidence in deleting useless stuff (that you can recover later).
You can have a git repo on a server that developers use ssh to access just with git. The bells and whistles aren't part of the core job. It's just my general griping about software these days.
I get where you're coming from, but I still don't think it deserves a ??. Most people in most environments want a GUI they can click around in.
I'm very comfortable with git at the command line, but I still think it's valuable to have a web interface. For instance, with a web GUI I'm able to share a link to a specific line or range in a file in a specific commit.
Typically if I need to do that I'm asking a question or requesting a change, and in that case I want there to be as few barriers as possible to increase the chances that the other person cooperates. Asking someone to clone/pull the repo, checkout a hash, and then view a line in a file is a much higher barrier than asking them to click a link.
Linux is one of the most massively distributed projects in the world, and it just works fine without GUI review tools. If Linux devs don't need such tools like gitlab, why you?
> "What are the arguments against version control here (if any)?"
No good ones of course, but there is one that I think is superficially very compelling:
It keeps a permanent record of everything that has ever been part of the codebase. If HIPAA required medical and patient data to not be stored anywhere except under highly controlled circumstances, the CEO might be afraid that data might end up in version control.
And that's not an entirely unreasonable fear; developers writing a quick PoC could include data in the project because it's quicker than setting up the infrastructure required. And of course they'll later fix it, but the version control system will still keep a record of it.
Of course there are tons of bad practices about this, but here's the thing: bad practices do happen, even if it's just as a temporary measure, and version control will create a permanent record for that.
Of course the right way to do this is to ensure that the developers only have access to anonymised test data and not to real sensitive production data; and to ensure that production data is always and only stored under the proper, secure circumstances required.
It's still a red flag, but the reasons might be more subtle and complex than simply "I don't understand it".
No offense, but starting to code professionally with only 15 years sounds... a bit strange? I mean, I started coding with 10 (~20 years ago), and the easily available tooling was much worse back then than it was 5 years ago, but if I was your CEO I wouldn't put anyone with that little expertise and (I suppose?) no formal training on such a project alone (it's something else if you're working with a senior dev from whom you can learn). And when I was your age, I wouldn't have done anything that might put me in jail if done wrong.
Also, please pass this message from me to your CEO: He's an idiot for not letting you use version control.
You're not storing patient details in VC...... Right? Maybe show him that you can run svn even on his own machine... Anything... Anything is better than not using something
I've work with HIIPA and VC. No issues, as long you do not store patient information within the source code, I cannot think of any reason why you would need to do that...
>I'm very junior, been coding for ~5 years, 3 professionally
I agree with everyone else commenting here. This is a disaster waiting to happen. You are also limiting yourself by not working with people who will mentor you and show you the correct way to do things.
You're experienced. You can find a new job. DO SO IMMEDIATELY. FIND A NEW JOB, NOW.
Seriously, the GP comment makes me wish I had a job to offer, not just due to sympathy but because any 18-year-old who is even sort of managing to tackle that problem and also knows that lack of VC is a serious red flag is probably worth an interview.
Wow. Just wow. Run. There is no way this will end well.
No version control = no way.
You're junior in years, but 3 years working professionally makes you perhaps less junior than you think. It's right around the point it becomes easier to get other jobs.
Before quitting, try your best to make changes that will reduce stress and improve the project's manageablity with or without permission. Your work sounds so mission critical you could probably do whatever you want with no chance of getting fired.
Just be able to justify your action and communicate your decisions clearly. You'll start earning respect and that alone will reduce your stress levels. Standing up for yourself is hard to do at any age and "learned helplessness" is a concern if you don't push yourself.
Giving a demanding task to a junior is usually how they improve and learn, but what you describe here is just a big pile of management incompetency. Escape.
This smells like you are being set up to take the fall for something. Possibly something with really serious personal legal consequences. This is way, way worse than being underpaid or working for abusive jerks. No way it's worth it, I'd say quit now, even if your immediate alternative is working at Wal-Mart or something.
I know the feels but I'm a bit older. I am currently rewriting an old web forms app. Source code is outdated and not what is in production. Some methods are 1500+ lines of code. This project is dumpster fire but at least I can vent to everyone and they agree. Plus, I don't have to deal with HIPPA good luck brother!
> expressly forbidden from using ANY VC by the CEO [...]
I read this and thought this could be because the CEO only thinks of version control as "GitHub", and is worried about putting sensitive information in the "cloud".
Have you considered discussing this with your immediate superior? Not using any VC is a disaster waiting to happen...
EDIT: It's like the first time I saw The Rock. I thought his head was too small and his face was stupid. Now I love Dwayne Johnson.