Storytime: My new internship - Advice?

Well, the post was an interesting anecdote into the life of a 2024 intern, and I trust I made my position clear early on. To go off on a tangent rant, I've been doing systems design since the 1980s and I cannot tolerate environments where the IT minions treat me as a security risk and wont let me administer my own development resources. Cannot tell you how many times I've shown up at a new contract customer site, only to be given some crappy office intern netbook, running windoze, totally locked down to where I cannot even stick anything in the USB slots, and then told to do firmware/OS level systems design. I'm beginning to walk out quickly with more and more frequency as that attitude become more common.

IMHO, it's all about IT being lazy. Back when I had to sysadmin large unix systems and do network management, we were not ALLOWED to restrict developers from having root access on development systems. My rule was, you get sudo (minus root shell). I expect an email stating what and why, if you make any system change. If you don't keep me in the loop, or you do a root shell to bypass sudo logging then you lose root access. I only had put on the gloves on once, with a couple of Oracle database devs who thought they ran things. I ended up quitting because management sided with them.

Other laziness with IT is that they either dont know how, or dont want the overhead of sandboxing the development subnet and then letting us r&d guys manage it.

And don't get me started on VMs running under windoze. You dont do firmware or simulation software under VMs, ever!

Probly a good thing I'm at the end of the rat race...not sure how much more I can tolerate.
 
Well, the post was an interesting anecdote into the life of a 2024 intern, and I trust I made my position clear early on. To go off on a tangent rant, I've been doing systems design since the 1980s and I cannot tolerate environments where the IT minions treat me as a security risk and wont let me administer my own development resources. Cannot tell you how many times I've shown up at a new contract customer site, only to be given some crappy office intern netbook, running windoze, totally locked down to where I cannot even stick anything in the USB slots, and then told to do firmware/OS level systems design. I'm beginning to walk out quickly with more and more frequency as that attitude become more common.

IMHO, it's all about IT being lazy. Back when I had to sysadmin large unix systems and do network management, we were not ALLOWED to restrict developers from having root access on development systems. My rule was, you get sudo (minus root shell). I expect an email stating what and why, if you make any system change. If you don't keep me in the loop, or you do a root shell to bypass sudo logging then you lose root access. I only had put on the gloves on once, with a couple of Oracle database devs who thought they ran things. I ended up quitting because management sided with them.

Other laziness with IT is that they either dont know how, or dont want the overhead of sandboxing the development subnet and then letting us r&d guys manage it.

And don't get me started on VMs running under windoze. You dont do firmware or simulation software under VMs, ever!

Probly a good thing I'm at the end of the rat race...not sure how much more I can tolerate.
Actually, on the job that I wrote the long post about - USB sticks are actually prohibited on Windows systems. If you need to move a large amount of data, use fileshares.

If you need to be able to compile something, ask for a dev-grade computer, it will be yours to administer, just make sure it stays compliant with employer's IT policy.

If you want to do firmware design - sure, buy whatever hardware you need and have the budget for, the network just won't let the test devices on. If you need network access for your project, use the R&D network, not others.

and VMs are perfect for simulations.

Root access on a server is definitely NOT a Best Practice for development and testing. There's a pretty good discussion that you might want to read about why people are rethinking their stances on trust and security in software development: Thread backdoor-in-upstream-xz-liblzma-leading-to-ssh-server-compromise.92922/. You're not the only party to the story.
 
Will read your post soon ^, after this. :)

Quick update #2:

As of the custom employer/employee personal growth meeting (no idea what to call it) this Tuesday I am now the only employee with a prohibition of hosting any meetings on the workplace.
And of course I found another issue that had to be patched.

Apparently yesterday there was a problem with the live website that I didn't get any tell of since I worked from home - so during today I found out some of the set price services, that our customers order, were set to 0 USD instead of the usual 200-600 USD range. The issue was reported yesterday when it was found but set on ordinary priority (for reasons who knows).
I showed my leader in charge, who I must report to, that there are ways in which bookings still can go through for the 0 USD price. [And also only one caring about that there are trade laws and requirements for set prices for online orders is me.]

Now when they have started to listen they made an update of the report to the dev team and this time with high priority so it was patched after two hours.
Up until now I thought we dodged the bullet since I had mostly theorised about those 0 USD bookings getting accepted in the system.

1 more hour, I get first request from a customer wondering why his service costs 0 USD, and I was like "Oh boy, just dandy luck we patched this monstrous thing".
I addressed the issue and informed all clients about the issue and that we had patched it. I also personally did a damage control with the limited resources I sit on and went through the bookings I could access from the time the error occurred (which I could only guess in this non-organised business). Luckily again I only found one other 0 USD and I suspect there may be at most three more of them during the time frame.

My leader in charge was confused when I told her I would do a damage control, and I am confused as of why the dev team push a faulty frontend to backend access. It's as if they don't even do local testing on beforehand since it's not the first time I notice a broken push.

My suggested solution, in my report, in meantime would be to put a simple 404 handle on the malfunctioning services, since that is what any sane developer would do instead of having an open route taking requests that should never take place.

This was today's harvest.

Side note: When pointing out to a colleague what a sandbox environment the booking system is he told me to never tell the system admin about it - she has been in charge of and managing this for seven years. No wonder she got upset over my findings.

/MH
 
IMHO, it's all about IT being lazy. Back when I had to sysadmin large unix systems and do network management, we were not ALLOWED to restrict developers from having root access on development systems. My rule was, you get sudo (minus root shell). I expect an email stating what and why, if you make any system change. If you don't keep me in the loop, or you do a root shell to bypass sudo logging then you lose root access. I only had put on the gloves on once, with a couple of Oracle database devs who thought they ran things. I ended up quitting because management sided with them.
This lazy part is so toxic though when it is linked with company losses. I respect that you can have a developers environment and let everyone in the dev team have permissions to do the job. It's just little different from this situation where every person on the team, out of hundreds, have direct access to shut the whole thing down. It's far from any local development, it's countrywide coverage with every change going realtime, at the same time we have disgruntled employees with said access. I would never construct the system in this matter. It is almost prone to selfdestruct just by working.
 
Welcome to the real world; what you are describing sounds like most places I’ve worked and unfortunately I don't think you are going to win friends with your approach.

I‘m not saying you are wrong in trying to get things to happen but your descriptions sound like you are likely to be rubbing people up the wrong way.
 
More than 15 years ago, I worked at a small shop where a single server box with SCO UNIX on it ran nearly everything, from web server to email to printing to customer database. Even back then, everything was horrendously out of date - the database was flat .dbf files... I was the only IT guy in the house, managing a server that the owner's techy friend set up. The techy friend was competent, and frankly quite supportive when I tried to move stuff off that box onto something that is up-to-date. It was 2006 at the time.

I did set up a FreeBSD 6.0-RELEASE server to run the company's email on a separate box. That did make a huge difference, receiving email no longer resulted in server crashes that brought all work to a grinding halt at that shop. I also read some notes left behind by previous admins - all of them urged the owner to move the database to MySQL, but it was a no go, the guy was stubborn. Not even the idea of using devel/ncurses in conjunction with the migration (which he never understood anyway) would convince him. I was a part-timer who came in 2-3 times per week for a few hours to clean up the crashes. Eventually, got fired for not doing stuff beyond my contract. I guess these days the term would be 'misunderstanding of the scope of the contract'.
 
Welcome to the real world; what you are describing sounds like most places I’ve worked and unfortunately I don't think you are going to win friends with your approach.

I‘m not saying you are wrong in trying to get things to happen but your descriptions sound like you are likely to be rubbing people up the wrong way.
It's better to sail with colleagues than to sink amongst friends. xDD
 
Back
Top