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
This entire thread discussion is filled with it's not worth it, but towards the "no one should be forced to work like that" kind of way
The data and application code are probably very intertwined, rather than portable code that could be plugged into any kind of stage database.
I'm finding myself hoping that this is a fake, because I wouldn't wish this situation on anyone at all.
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.
Might be able to quit the job, turn them in for HIPPA violations and also claim unemployment (source: I did this at a job that was violating HIPPA)
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.
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.
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..
https://www.medsafe.com/blog/compliance-topics/7-common-ques...
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.
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.
Complete insanity.
But yeah, get the heck out of there.
Change management is part and parcel of anything in the medical software domain, and VC is an obvious part of that.
Version Control is a basic requirement of professional software development in this day and age.
You could try explaining to your CEO it would be like telling a carpenter they can't use a hammer to build your new house.
Or just take the initiative and use Version Control without telling them. In my mind it isn't something you need to ask permission for.
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?
Easier than you'd think, or at least I could see it happening.
Yes, nail guns are awesome, but hammers are very useful tools.
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.
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 very probably is the opposite. A lot of people who end up working at 18 are doing it because they need the money and their support network is poor.
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.
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've been there. Run.
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?
Unless these are 'CEOs' of 3 people tech companies, I guess.
Gotta love those companies where there are more board members than employees.
Then again, this isn't a tech company.
- Hey Joe CEO, which version control do you think I should use?
- None, that's an order!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.
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.
EDIT: And don't forget remote options.
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.
https://docs.google.com/spreadsheets/d/1JfNAbUX_lN9K3MCNHO15...
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.
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.
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 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.
You're a programmer, not a fall guy. You aren't getting paid enough for this.
1. I’m impressed that you’ve made it this far.
2. This situation has ‘get the fuck out’ written all over it. It’s time to dust off your resume and get out of there.
3. I don’t think you’ll have any trouble. You seem like a good writer and I bet you’d be a good developer to work with.
Best of luck bud. I wish I had a concrete way to help you.
There are plenty of jobs out there. Go get one, _today_, please!
Honestly the project sounds quite interesting, but I can imagine the circumstances make it painful.
* 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.)
the list goes on...
You've never looked at a piece of code that you wanted to see the history of?
You've never needed to revert a single change a few hours/days/weeks later?
You've never needed to track down the person who wrote a piece of code in order to ask them for clarification?
You've never needed to see the original change reason for a line of code that is doing some weird, specific thing that seems out of place?
You've never needed to have two people edit the same file at the same time?
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.
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.
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.
GitHub does, now, though I really hope that isn’t necessary for a company to adopt version control.
* 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.
What else are you gonna use? SVN? shudder
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.
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.
There's also this which is fantastically named! https://ohshitgit.com
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.
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).
I echo your ??. Sure you don't need a central repository to use git. What does that have to do with suggesting some git hosts that aren't cloud based?
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.
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".
Also, please pass this message from me to your CEO: He's an idiot for not letting you use version control.
Leave asap.
Did the CEO give a reason? I'm a bit curious based on it being billing and HIPPA. Also, are you rolling your own EDI import/export?
Yes, I just wrote an EDI exporter in Ruby for Medicaid services, working on one for MCOs now. Thankfully we don't have to import EDI, or I'd go nuts.
Unless you have patient information hardcoded into the source code for god knows what reason...
Hosting git externally might be an issue though.
Just show him that you're literally only committing code, and not any real data in the repo.
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.
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.
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.
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...
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.