If you're hiring, be forthcoming about the dev experience
rachelbythebay.com
rachelbythebay.com
Company supplies horrible laptop locked down in ways that prevent any real work from being accomplished, but allows unfettered VM use because they don't understand or care about security outside of the environment they designed. Some developers use an underground system of sneaker net and whisper doc hodgepodge to get real work done, but that largely isn't a problem since productivity is measured on a political basis rather than getting anything accomplished.
Thinking you'll improve the situation for you and your group, you obtain permission from management to procure and install a workstation on your desk and replace its OS with Linux. IT drops the machine, you install the OS and enjoy much better productivity for a few months until a security flag is raised in a distant location and you're hauled in for an interview with HR and your boss, who now claims never to have given such approval.
Back to the VM no one cares about. You get a writeup and final warning, and because the economy is going to hell anyway, you stick it out, and things unexpectedly change for the better. Your boss quits, and everyone forgets about the writeup.
Years later, someone decides it's time for a Linux server push. You get tapped for that effort and can now set some policies. Its too late to help much though, since this is 2008 and this company is named Lehman Brothers.
It was fun while it it lasted.
I think developers assume those choices are made for political reasons "hey, I did something", but in reality we are often countering known mechanisms of infection propagation.
Remember what happened to Sony? So we disabled SMBv1 and PowerShell - devs complain. Then we see someone in accounting installed a fake version of Adobe something - so we prevent software installs in that department. Then a VP forces us to give him a "dev-mode" OS without restriction and subsequently gets a virus that brings down his department. ...so we have to then role those restrictions to everyone.
...and, you're right, we don't pay much attention to devs setting up VMs and tunneling around firewalls, because the vast majority of risks we combat don't use those methods. But once they do, yes, we'll lock them down too. (and VMs are becoming more common in malware space, fyi).
1. These rules are usually distributed via GPO, and the AD system it uses may or may not have a useful and/or well maintained notion of who is a "developer". At best it's done at the departmental level, which isn't that great - since a lot of IT/dev people work in all departments.
2. Whenever you make an exception to a rule that restricts behavior, it's always the worst actors that game that system to get the exception. It's exactly that one VP who thinks he's tech "enough" to handle the risk that'll figure out how to get the exception for himself - he's also the one to run a torrent client to download a free copy of "PDF Writer" or a malicious keylogger.
3. GPOs can be complex to apply - errors happen. The simpler you have your rules, the less likely there is an error that leaves core/critical systems unprotected.
A funny thing happened after I started to work - IT department was unable to procure me that laptop. After ~3 weeks they said that the company they order hardware from can't provide Thinkpads for the foreseeable future. So I've asked to just order from Amazon or similar. Nope, can't be done. My manager just shrugged and told me to ask for standard Dell laptop like everyone else in the company. Yeah, it arrived on my desk the next day. Later I found out that company works like that in many different areas. Lots of freedom and choices on a first glance, but once actually needing something, there was always only one way to have it done. Usually the most annoying and time consuming way.
So, the interviewer wasn't wrong in telling me that I can choose what I want, but the company makes sure everyone ends up with the same setup. Somewhat similar to Henry Ford's "you can pick any color as long as it's black".
But they also don't lie about it.
So many security issues with that - that it was never a reasonable request on your part.
Moreover, having also helped with support and procurement. BY FAR, the most efficient thing to do is get the exact same laptop model for everyone. Otherwise, the IT support team is constantly fighting with driver and support issues on different brands, models, bloatware-in-drivers - a new battle for each configuration.
One-size-fits-all laptops for the company makes 100% sense for a company.
as to non-engineering / technical staff, though i am general allowing people who care strongly about their setup (for good reasons, mind you), while having the vast majority of people (especially the ones ambivalent about setup who simply want the smoothest possible experience) on a constrained, non-fancy-whiz-bang-corporate-it-3000-or-whatever setup. i also freely acknowledge that there are extra costs to this mindset, and people are fee to assign their own values/prices/costs to these things as they see fit (all other things being equal).
It's a reasonable request.
When I was young, I considered this to be exciting. These days, it makes me never want to switch jobs again.
I figure after 2 in a row, the next place has got to be step backward a good 5-10 years. I'm putting it off as long as possible.
Though saying that the first place I worked was firmly stuck in the 1970s so maybe I got it all out the way in those first 3 years.
At one company, I was handed laptop with an older version of Windows, preinstalled bloatware, 3rd party encryption software, anti-virus, VPNs, etc. Even worse, the laptop was about more than 16 inches and weighted over 3 kg because the company crammed in as much expensive hardware in it as possible -- so that the computer would fit everyones needs.
I understand the need for company IT policies, but global companies have such complicated policies it basically hindered all my work.
You won't believe the sigh of relief when I started at a small start-up company, and I was able to choose all of my hardware. The CTO ensured my SSH keys would grant me access to all the servers I would need.
There's nothing wrong with standardization as long as the standard laptop isn't crap.
Where are you from? Thats a heck of a mix between imperial and metric.
My heart sank and felt I took a bad turn in life. I really wanted to work there but I had stopped using Windows for health reasons a long time ago. I wondered if it were rude to resign the same day because there was no way I would use Windows. I thought it was more honest, but at the same time I thought I may be too radical. Maybe I could be spared and still work there. My brain went into overdrive. The CTO then said "Uh, I mean Linux.", he noticed my face and continued "Don't panic, there are no Windows machines here". The whole thing lasted a few seconds.. I heaved a sigh of relief.
We try to be brutally honest with applicants, not only with the hardware but on the specifics of the job. It disappoints many who imagine they'll be doing "data science/AI" with screens that blink and computers that beep.
How does Windows cause health issues?
Edit: Ah, I see, you removed the violent rage towards machines running windows part.
If you kick things just because you're irritated, please seek professional help, and don't blame it all on Windows.
It is not that Windows caused health issues, but my reaction to Windows was not healthy. Bear in mind that before switching, I had only used DOS but mainly Windows for almost two decades. Let's say we grew apart over the years.
My job was supporting, enhancing and debugging internal tools used by engineers. Upon arrival I was handed a USB key with ZIP files of the source. There was no source control. I initiated a request and the political process necessary to 'allow' me to use source control and setup an SVN (this was quite a while ago) server. I quit in disgust a year later, and the first meeting to discuss whether I should be allowed to use SVN or not was scheduled for the day after my departure. My last work action there was to leave a note on my desk advising my replacement where the most recent ZIP files of source were stored.
None of the above was explained to me before I was employed, and I've since learned not to assume, and explicitly ask "Do you use source code control?" and other basic questions at interview / contract negotiation stages.
So did I, but when they told me "Yes", it often turned out to mean "Yes, but only in a few departments; not the one you will be working at", and in one case "Yes, but we only use it as a backup system for the completed project, not during development".
Asking the right questions is important, but it's only half of success; the other half is getting truthful and non-misleading answers.
Edit: what did you mean by "a set" of standardized toosl? Like the set {Windows 10, Linux of some distribution, macOS 10.15, iOS, Android}?
Even then, what if some app does not work on Windows 10? Or what if you need a 32 bit app running on macOS?
Edit to your edit: whatever particular sets of tools the business needs. Whether it’s laptops, thin clients, operating systems, IDEs, ticketing systems...
> Even then, what if some app does not work on Windows 10?
If your business had standardized on Windows 10, then you’d hope checking whether things worked on Windows 10 would be part of their procurement process.
> Or what if you need a 32 bit app running on macOS?
You choose something else. Like any business running MacOS would have to do.
Like the body, everyone's brain is different.
Small organisations have the luxury of letting people choose their tools more freely. As they grow, they tend to have to restrict this more. Not just because they might have to support the tools you choose to use, but because they absolutely will have to support how your choices work with all the other tools they have in the organisation. At scale, this starts to get out of hand pretty quickly, and the only way you can provide a good working experience is by adding constraints to the tools used.
On top of that, some organisations have regulations and compliance requirements to meet that make it even harder. If your basic procurement pipeline includes $10,000 of vendor due diligence, then you don’t want to just give everybody free reign to use anything they feel like. If those choices introduce additional ongoing compliance costs, then you want to control that even more so.
You could ignore all of that, and focus only on how it affects you. But there’s good reasons that organisations do that sort of thing.
If policy is install whatever you want, and if you get hacked, you're fired! This just won't stand in court. So policy is that IT department is responsible for installations, IT department gets the blame. Infrastructure is sort of "outsourced" within the company.
If you were accountable for those younger first-timers running I2P and Tor within security perimeter, what would you do?
It may be correct for them. But for you, as a candidate, it's a good indicator that you'd be happier in the kind of company where engineering has the power to get that done.
Between jamfcloud, osquery, munki, etc. there are plenty of companies and tools out there catering to IT departments that take this seriously.
Happened with me as well (but I use a macbook). I won’t call it draconian. The IT department usually has to deal with a large number of hardware/software support requests on a daily basis. It’s quite understandable that they won’t have all the answers for a platform they’ve never used/supported before.
And, in any case, I wasn't asking any questions about Linux, I just wanted to connect to the network. My current company lets me use whatever weird distro I want (even Arch, btw), but they won't officially support it. That's fine. I can, however, ask them to support standards that I need (rather than specific support for some distro).
Don't get me wrong, there are bad dev experiences that can be had. However, from my experience its definitely not mac vs linux vs pc, but rather intricacies that are unlikely to be able to be explained during the recruitment process. And if they can, why would they? It's not like applicants are being super truthful on their resumes.
One problem with building upon a framework of falsehoods is that to be a consistently effective liar, you have to have a fantastic memory to keep your falsehoods referentially consistent.
When I was on the proverbial other side of the table helping to evaluate candidates, I became flabbergasted with the frequent false skills claims of candidates, especially those sent by job shops.
To me, it would be exhausting to be phony. I'd rather save that mental bandwidth for stuff I can feel good about doing.
Like that time they were at a book signing event, asked the author for a two-shot, got a smile for a last joke thrown before leaving for the next in line, and now proudly declare themselves “good friends” with that author.
I assisted at whole interviews where “tech leads’ craftily avoid recognizing they code at most half an hour a day.
Or a dev listing super hard stuff on their resume but never mentioning until thoroughly asked that they pair programmed all of these.
Personally I find pair programming hard stuff way better, because your constantly talking about the challenge a find issues earlier than when you just implement your initial solution.
I never thought that is somehow bad, but I guess people have different worldviews
It’s like co-authoring a book, that’s fine, but don’t just say “I wrote a book about xxxx”, be upfront about cowriting it.
Once I had an interview with a guy who claimed to be fluent in several languages, so as a warm-up question I asked: "tell me any difference between Java and PHP", choosing two languages he claimed to have most experience with. After five minutes of silence, I gave him a fizz-buzz-like test, just to be sure I am not mistaking something else for utter lack of programming knowledge; and he failed at that, too. But until the technical part of the interview, he made a really good impression; good fashion sense, great verbal skills, interesting CV. I think this guy would easily agree with any manager that the importance of a specific programming language is overrated.
Ironically, a similar attitude might also come from the opposite side of the expertise spectrum, where the person would roughly mean "PHP is Turing-complete, Java is Turing-complete, Haskell is Turing-complete, Lisp is Turing-complete; what you can do in one of them, you can do in any of them". Like, sure, given enough time and an infinite Turing-machine tape, of course you can. But if someone has dozen years of experience using language X -- not just the language itself, but the entire ecosystem, like knowing the best practices, good libraries, good build tools, et cetera -- how much time would it take them to acquire equivalent knowledge of language Y and its ecosystem? Especially considering that the typical employer will spend $0 for training and requires full productivity from Day 1.
> It's not like applicants are being super truthful on their resumes.
Relevant: https://www.joelonsoftware.com/2005/01/27/news-58/ Horrible developers are overrepresented at job interviews, because the decent ones usually get the job and the horrible ones have to try again, and again, and again.
If you invite only those with good resumes (makes sense, why would you invite those with bad ones?), you mostly get an intersection between people who suck at programming and have great resumes. That means: liars.
When I took the training class, I assumed it was all about not asking questions we could be sued for, but that probably took up about 5 minutes of the class. Instead, the instructor created exactly the scenario you described. Someone who sounded really, really great and who you'd like to work with, until you thought about what you heard and realized he hadn't told you anything at all.
Good con artists are really good. Even if the average interviewee isn't trying to pull a con, digging into their real experience isn't something we're all good at. Training helps.
Prod is something that runs in the cloud, staging is something sorta like that, but the data is garbage and nobody maintains it, and dev is whatever someone could cobble together in a bash script to get something running using homebrew dependencies -- if you're lucky.
Or everyone hopes to docker-ify everything, but that's its own pile of garbage.
It's actually k8s-ifying everything (docker-ifying was 2015-2018).
> nobody really embraces the zen of devops
I know exactly what you mean, as am struggling to get people around me understand the value of tooling, developer delight but to no avail.
Management, other non-tech teams (sales, product, Ops etc) that have learn/worked mostly in regimented setups have a long long way to go before they even start to understand what DevOps really was supposed to be - all about actionable faster feedback loops.
But, faster, actionable feedback loops also bring out the the orgs's / dept's systemic rot/muck in policies/deficiencies/politics and make it visible in-the-face. That's very threatening to many who put up a make-believe fakeshow that "our stuff's all cool, that other team/dept has all the problems". Hence, all that pushback against the new or throwing the tool in (docker/k8s/cloud) and claim that it would act as deep magic to fix the fuckery happening all over.
I learnt it over my exp at big, small, medium sized firms - over last 15+ yrs.
Only way to get to achieve DevOps (yeah, not "adopt"; one can't just 'adopt' that) is to get CTO/COO/CFO to really really understand the value. Else, lost causes!
Why would you write this article from an engineer's standpoint with arguments that will only benefit other engineer's but for some reason is directed at companies? Why not just call it "I'm upset with the dev experience" and be honest about your intentions?
which implies she thinks companies should tell potential hires you won't like working here and should run away, which I doubt many companies will listen to that advice and think "sounds good".
That said what you said would be a good thing for companies who are afraid to tell what their dev experience is like to consider.
So again, I don't think relying on companies to tell you the things they know their employees don't like about them when they are trying to get you on board will be seen as a winning strategy.
Yes, people desparate enough to subject themselves to poorer working conditions. What's the single benefit for companies to cut themselves off from potentially good employees?
This goes along with a broad category of attempted deception that fails because the person you're attempting to deceive has, typically as a part of their job, understanding the actual state of thing you're trying to lie about. Especially egregious when it creates a safety risk, for example, but bad enough when it simply wastes time. Good example: Lying to accountants about the contents of financial statements.
Engineers don't want their time wasted, but companies have no benefit in trying to prevent it as far as I can see. What kind of brand image would they portray if they started saying how bad their tech stack is?
I've also worked for extremely corporate companies, and a lot of the saner people backed away slowly during the interview process, but some people took a week or two at the company to register "yes it's really that bad" and bail.
I talk to my manager, get an approval for a headphone and email IT. IT refuses. Since I persisted it got raised to the IT head. IT head calls me in for a quick chat and told me we cannot cater to the whims of every employee. I got told off that I should know my place as a new grad. I offered to use my own headphones, but requested an adapter since the mic/audio were on separate ports. Adapter costs Rs.300 ($4) on amazon. Headphones cost Rs.1000 ($14). Now my keyboard and touchpad sucks too. Overall I have invested more from my own pocket to work with this brick. What I learned from talking to others was that they just recycle laptops and give to employees. Say Emp N and Emp N+1 complain about laptops, they give them laptops which belonged to N-1, N-2. Basically the last laptop they received goes to the next person.
And yes I am stuck with a 4GB i3 Windows 7 (no budget to update windows) with an Ubuntu VM. Good luck running docker on windows. Not to mention the daily rite of passage (BSOD) after 10 mins of booting up.
Some general things I'd quantify as making a "good" environment:
- The time from saving a file and seeing the change should be low
- Running the environment is complete, just like production/staging
- Database schemas are reproducible and in a single location
- Intermittently issues due to differences between machines are nonexistent
- A debugger can be hooked up to the process or otherwise remotely debugged via network
- Very little configuration necessary
- Ability to use third-party APIs for integrations and infrastructure dependencies
- Any crons or async tasks are easy to run
- No other arbitrary limitation on access that get in the way (it is just audited if necessary)
- [If allowed] production data can be pulled in for testing
1. Build tools/dependencies from source on macOS and Linux
2. Use an OS agnostic init (supervisord)
3. Automate machine setup and deployment in something like Ansible or Saltstack
This allows you to bootstrap a bare macOS or Linux system with a smallish shell script and run all the necessary services in the same way they'd run on production. You have very little specialization between production and dev -- like in the cloud you just run Postgres, you don't use RDS on Amazon.
Coincidentally this makes supporting multi-cloud or bare metal very easy since you don't use anything that's really special in any cloud. Like I would run our main thing on ec2, but CI/dev workloads on Linode where I can get cheap VMs.
Most of the piecemeal automation - migrations, cron were just tools written in python - some were daemons, others just scripts that ran during a deploy.
Macs can be requested for devs but Windows is still the default for users. lots of services being migrated into azure/office365 means no longer needing the VPN for everything
but sharing large files is still primarily done via mapped network drives, which requires the VPN.
Security team unfortunately MITM SSL which means breaking random things like raw files on github (thanks Cisco).
Most of us have the freedom to spin up local vms/docker for dev environments and easy access to AWS and Azure for spinning up test/prod servers.
No real standouts, but the team is great and the work is interesting
EDIT: I should also note, this is an old school engineering firm, not a tech firm. Change is slow but it does happen
My main pain points were related to filesystem access, primarily its speed for things like npm install and running test suites.
Though if you're just using a docker image through wsl2, does that alleviate those issues?
I can appreciate wanting a fast NPM install, but how often are you doing that that it's any kind of significant?
I mean SSL MITM?!
All while trying to get them to improve their policy, of course.
but yes if we want too there's no rules against using our own machines.
We can login to things like the company github etc using sso/ssh from our own machines, just not the Intranet services.
You PC (Mac or Wintel) is just something to run your editors xwindows what have you like company C
Windows has seen the light and plenty of Unix possibilities on Windows, but they have lost nearly a generation of Developers who don't want to move back.
I personally don't care, I have two macs, one windows, one Ubuntu, and several tablets to work on. OS's are pretty commodified.
Setup a VM, getting networking going on the VM, blah, blah, blah.
Mac actually supported Linux commands, windows didn't.
That or you had a Linux laptop which had a massive overhead in breaking a lot. Never did it myself, but the complaints tended to be that drivers broke constantly and it was hard to use a lot of commercial software, including games.
As far as I remember, it was common even 10 years ago to see Linux users on HN openly say they'd given up on trying to get their soundcard to work as it wasn't worth the hassle as it would just break in 6 months again.
And why would you be running games on your companies Linux systems ?
People paid for simplicity. Engage your empathetic brain to understand why people don't want to make their lives complicated, instead of trying to invent another jury-rigged workaround.
You can go dig through the HN archives around 2005 when everyone started switching to Macs. You will see the people delighted with their purchase in the comments, how much easier it made developers lives to have a working, powerful laptop that actually supported Linux commands.
Company X did well to preserve their own culture after the acquision, but despite that they didn't deal with sensitive information in the same capacity as Company Y, Company Y's IT security policies took over and made life miserable for devs.
When every task you do is wading through a slog of VPN and RDP mollasses, it's no surprise that so many devs quit.
The only reason the project I worked on got anywhere was due to some insidious tricks to punch through firewalls and basically hack into our own dev environment.
Now there are so many applicants for one job, I am sure they will. Especially if the dev experience is miserable.
aaaaand that's why they're not forthcoming, yes. -.-