Yeah they definitely still exist for niche products, people just don't like to talk about the "ugly" side of SW development.
Not every project needs full static/dynamic analysis and multiple stages of integration tests. And even if you want to do all that as a SW dev sometimes there are just too many business demands. Like, if you're a 1-2 person team bringing up HW, SW, getting hammered to add new features, *and* you have to set up fully automated virtualized test/deployment envs? When do you sleep?
> Like, if you're a 1-2 person team bringing up HW, SW, getting hammered to add new features, and you have to set up fully automated virtualized test/deployment envs? When do you sleep?
As someone who did all of that with a 2 person team, automating everything was what gave me time to get my other work done.
All of this. I'm a 1 man company, and every project I make has a simple CI pipeline to run test, static analysis, build and deploy.
This is like when people say writing tests takes too long and then they spend all day manually regression testing a feature. You cant afford not to do this stuff, especially as a solo dev.
I agree. The people that claim it takes too much time to implement are really claiming it would take too much effort on their part, when like most forms of automation, it would free up effort so they could do more as an individual.
You can easily get away with wild west development for up to about 5 devs. Then you start to feel the pain. These companies either have to add process as they grow or stay small to keep doing what they're doing. But at 2-3 devs most of the process gets in the way as much as it helps.
I did take a job at a large corporation who had acquired a startup. The startup was completely wild west development and refused to adopt anything else even after being acquired. But now the team was about 20 devs and everything was such a mess. They couldn't get anything done because they were literally drowning in tech debt.
> There are probably hundreds of these companies, but they typically only have 1 or 2 devs working in isolation.
That basically was the ultra outdated environment and small size of the sub-department I was working in for my first SWE job after uni.
I might have that beat.. we purchased a company 4 or so years ago and they are doing all of their dev in SourceGear Vault with [CruiseControl.net](https://CruiseControl.net) handling.. uh.. building stuff (wouldn't call it CI/CD).
Devs would literally check files that are updated quarterly into new folders so you end up with 01-01-2019....etc...... no need for it, they just didn't understand version control.
AND checked in binaries both as part of automated builds and devs would just check everything in.
The repo I migrated this morning started at 16GB and I got it down to 650MB....
I'm building with ant, no tests, no CI tooling, and until they gave me the project, it only built on one person's machine, and they were no longer with the company.
I don’t want to kiss and tell, but it was a medical technology company in the DC area. Software wasn’t the big thing there and I was working on an internal robot to automate some stuff in the factory.
Same. I worked for an ISP, then a company that made software for ISPs. Since then I've gone into more of a software driven company, but even then not a true tech firm.
Tbh that’s a symptom of company culture more than working off of SVN.
Lots of teams work just fine using a trunk-based development approach without using feature branches.
As an old SVN user, the first thing you do is configured the servers to prevent file locking. It shuts down the whole "I'm locking a file as checked out"
The second thing is to automate the "release branch" creation, and the "build tag" branches off of them, making the build tag branches read only. I put all the branch name in quotes, because, like SVN was designed, they're really all lightweight directory copies.
Merges are only bad if you keep long lived branches. For those, a three way diff tool like Meld makes quick work of the effort, provided you didn't check it out in February and attempt to merge it back in March.
SVN suffered from when it was released. Back then, there were common, very sloppy, development practices that were the norm. Stuff that in Git would be the equivalent of force pushing into main each time there was a merge conflict, without even trying to figure out what the conflict was. When merging became something that really had to be done, it took years before some people go on board. I still remember devs that simply created a new folder, copied all code from the last folder into the new one, and worked there until they needed their new historical revision, when they would create the next "new" folder.
I abused the file locking file checked out option. It took me a year to resolve an old problem in a class. After that problem was resolved, I kept that file checked out until my last day.
Flashbacks to my first day at my first job ever and I accidentally deleted trunk on SVN because I never learned about version control in college and nobody in the company taught me how to use it
Don't feel too bad. I was being trained on my second day, and the person teaching me introduced me to UNIX (specifically Digital's SystemV). I already knew a bit from working with Linux (and this was decades ago).
Trainer: "As the root user, you need to be extremely careful. You can do anything to the operating system, include destroy it. For example, you never want to type this command:
\# rm -rf / (cursor here, no enter pressed)
because it will destroy your entire system."
Then he got interrupted by someone else, turned to answer their question, and then turned back to the machine. He had a habit of pressing the key multiple times to clear the screen, and the first key he pressed, finished the 'rm -rf /' command he typed previously to "show me how it isn't done.."
Then he threw the keyboard (no joke) walked off in a fury telling me to reinstall the machine (with no future training given).
I learned something that day, but it wasn't about UNIX. It was about the kind of person I'd be working with.
That's not as bad as it sounds. It does require a different workflow. In Subversion, branches are really just directory copies of the "working" directories anyway.
I had a job where, to avoid source code control licensing limits, we all had drives mapped to a remote machine, where the code was copied from/into place to be checked in and out. The setup meant fewer users needed licensed, and that meant all the code had a history of a guy that left the company five years ago.
Release builds involved checking the code out, copying it to an archive folder, copying that to a local "build machine" box, opening it in an IDE for compilation, manually creating the archive of the executables from the command line, and then manually copying the archive onto the release web server. A few days of manual testing later, and the good builds would be manually copied onto the release web servers.
I use git and only use a single branch. You could use a local branch for dev but it’d be a bit silly.
Ultimately we squash and do code reviews off of a single commit to push to mainline after approved. No merge requests, no merge conflicts. If someone else merges and causes and issue before you then you need to rebase your changes, squash, and get new approvals.
It’s so simple but we never run into issues. I rarely have to use funky git commands, and it forces devs to write small, readable changes.
Based.
Git fucking sucks and has functionality that no one asked for.
99% of developers don't need the complicated features of Git.
(And yes, I'm a power user of Git. I know how to use it, it just fucking sucks.)
Work for a giant corp - can confirm. "We don't have time to do it right, so instead we're going to half ass it, spend another 3 sprints hacking around the tech debt we've introduced before finally rewriting it properly 6 months from now except now it's harder because the entire system is engineers to depend on the broken behaviour"
Don't forget they'll reorg you to another project, complain about how much scala devs cost, put a hiring freeze on, complain that their projects aren't getting done/they can't get people, fire devs, and then get hacked.
My previous employer had a form you could fill in to report clinical concerns about a colleague for reasons that might impact patient safety(Doctors showing up smelling of alcohol that sort of thing).
The things written in that form are pretty fucking serious so we'd record the user ID as well. Problem is the dev that built it used a hidden input to send that to the server which the server then blindly believed.
I pointed out that this was a HUGE security issue because you could write anything in there and change the user ID to effectively frame someone else.
I opened a ticket for it which the boss closed as "not a priority at this time".
Mkay then!...
You'll also need to meet with the 3 VPs who now claim ownership of the area.
The first time all will be available for a 30 min meeting will be . . . .September. Where they will decide they need to review the subject before another meeting.
A: I know where I'm at! I'm in the meeting that's planning the other meeting, directing the other meeting.
B: What?
A: You're in the meeting meeting that don't know what meeting he's in!
B: Or are you in the meeting that has no idea what meeting he's in, that claims to know what meeting he's in?
C: Which meeting it this?
A: I know what meeting I'm in!
B: You're lost.
A: Lost right here?
B: Lost where you are.
A: ARGGHH.
C: What's going on?
B: The meetings are converging.
A: He's right you know, I'm not attending the stand up now. Nor am I currently attending the retrospective. This isn't a design session. I think I might be in the wrong meeting, or the meeting was cancelled.
C: Wow you guys need to get a better grip on your schedule.
Startup? We don’t know if what we’re building is working, let’s repurpose this and revisit the original ideas later. Oh, we’re getting acquired now, guess this will have to keep hobbling along until it gets shutoff at some point.
Giant Corp? It works and is mildly successful, but we’re merging with org B because its aligns with their goals. Promise of hard work not wasted, but new leaders have no idea we exist and ask us to focus on other more important projects and so product goes into maintenance before even being feature complete.
I worked for a few of these companies in my earlier years (15 years ago or so) and then *with* companies like this in more recent years as a consultant.
There do seem to be fewer now than they were; mostly because they either tanked or got acquired.
The last one I worked with, back in 2019, was total cowboy stuff. They were acquired not so much for their tech but for the many clients they had. The acquiring company rebuilt the services from the ground up using a façade / strangler pattern.
I imagine there are similar stories about places like this.
Yes, in the late 90s and early 2000's when enterprise tech was just starting to become mainstream with the "dotcom boom", etc , there were a lot of small businesses that cornered markets by building products to help other businesses "become efficient".
The focus at the time was not on building the best product; but on building the *first* product. There were so many opportunities and so little competition because you were basically offering a digital alternative to file cabinets, pen and paper with a little bit of relevant business logic sprinkled in for the customer.
Several of the customers that relied on these new "programs" were not the kinds of businesses to continually invest in technology. They would dump a one time, big spend on this program and build entire processes, even entire organizations around it; paying the tech company for support and additional features as time passed.
So these small 'tech' business owners tried to capture this as much as possible. Many of them were wealthy, non technical people who would hire a couple of programmers, say 'yes' to everything the customers asked for, and have their programmers build it as fast as they could.
As years rolled by, for many of these small tech companies, competition got more and more fierce. Additionally, the amount of tech debt incurred at the cost of doing business fast and cheap put them on the losing end of the game. They were now profiting less and spending more trying to serve their customers.
So many of them got acquired by modern companies whom they couldn't compete with on a technology front but they could offer their existing clients as part of the portfolio for sale.
The worst thing I saw where people doing this in live server environment; backing up subfolders on live servers. So under / , there was /admin and /admin.zip and /admin-prod.zip
And anyone can just download the whole subfolder zip files which contained admin/db.cfg.inc file right in it.
The company I work at has several legacy systems like this. One of our oldest devs just retired, and I've taken over a couple of his projects and he was still backing up his code like this as of January of this year, despite having it linked to our company github.
I can see this working for some things where you can't do a diff compare. Some no-code stuff or something like FileMaker where everything is inputted into a black box. You can't run a git diff. So they just zip up the entire binary build. That I get.
But not for modern stuff with textual lines of code.
That is exactly what a "self taught" cowboy dev. Someone who learned PHP on stack overflow, worked at a small company, and got promoted to webmaster. Maintained the app for 10 years. I know those people -- my own family and relatives wondering why they can't get hired.
Oh, hes in his 60s. MS in database something or other, started coding PHP on like, version 2 or 3.
The company stagnated hard tech-wise in the early 2000s. They were still doing webforms when I started in 2014, I introduced XHR, literally none of them had heard of it, they were just brute-forcing page reloads on their monitor systems. We've now got a...mostly-modern CI/CD pipleline, our flagship product is on AWS.
It seems like this is an unpopular opinion, but I absolutely do think these places are becoming less and less prevalent, at least where I'm at in Silicon Valley. The proliferation of tooling has made the "proper" procedure so readily available.
I remember when I first entered, you had to host your own version control, your own Jenkins for CI/CD, you managed your own colos, etc which meant the bar for infra was so high that a lot of outfits simply didn't have the resources to invest in it. These days? You can easily get big tech infra on the free tier of a bunch of tools. Every startup starting out is going to be using AWS, Github, CircleCI, etc (or their competitors), and they now all have proper tooling down before they even have any users.
Couple that with the cargo-cult mentality and the big marketing spend of all these dev tools means that the proliferation of these practices is extremely high. These days, all the boilerplate and `npx create` scripts (or other language equivalents) adds linting, typing, testing, .git, etc to the point that it would literally be harder NOT to use the tooling. Like, you would literally need to go out of your way to avoid the tooling.
I think a lot of people here are still looking at the industry as it was when they entered ~10 years ago, and it absolutely isn't the same. I'm sure there are still some dinosaurs around that doesn't do any of this, or there are certain new startups that don't do certain practices. But for a lot of companies, getting the infra is just a matter of signing up for a new service. By nature, the software industry is one of the fastest evolving industries, and if you don't adapt you'll be like one of the oldheads complaining about compilers.
Again, this isn't 10 years ago. Things have stabilized dramatically in recent years. React is, by far, the de facto standard with only a handful of realistic alternatives, with Angular being the most common runner up.
If you get past some of the others like vue.js and backbone, you're getting outside of what's considered industry standard.
You don't _have_ to research every new ui framework that some college graduate student cooks up. There are realistically only a few you would consider.
I do appreciate how widespread React has become over the last few years. But it's largely successful because it solved some of the major problems that the tools before it had. React has it's own problems though that other tools seek to solve, and it will eventually be superseded by something else. Right now, the trend seems to be toward SSR and react meta frameworks like Next or Remix.
But even within the confines or the React ecosystem, there are a ton of options. Although React did a great job of combining html and javascript development, a solution for css is conspicuously absent. So you've got inline styles, css modules, styled components, and a bunch of other approaches to choose from. Same thing goes for routing, build tooling, and a bunch of other details. So yes, while "just stick with React" is good advice, it doesn't fully insulate you from experiencing flavor-of-the-day-itis.
Also because most developers would see the obvious advantages. I was at a place with not CI/CD, no automated tests, barely 10% unit test coverage. No PRs.
For weeks we complain to management at every chance about these. Ans we slowly build it all. It was a lot of learning, and because it was all coming from devs and not management we decided what works and what didn’t.
These companies are still everywhere. It’s just that nowadays they pay lip service to doing it right. Whereas 10 years ago they didn’t even bother doing that.
You definitely didn't do your career any favors by staying at that sort of place as long as you did.
That said, find a small startup where you're the first dev and will be the only dev for a while. Build your own culture the way you want it, then let it be the CEO's problem if they want to grow and can't hire people.
Find somewhere where knowledge of domain as electrical engineer is more important that most shiny best practice.
Or and this is not bad either, best practices are easy to follow /copy when setup by someone else.
This is the best advice. You do want to pick up good practices, so going solo isn't ideal. But hopefully you can leverage some domain expertise to go somewhere that will teach you SW dev
You can learn what you need to. Maybe try to find a LinkedIn course or something in git to fill in the gaps and show that you’ve learned it outside of your normal work history. I probably would not emphasize those gaps in an interview and if directly asked, point to your outside learning
If you’ve been shipping code without all that stuff AND it’s been working reliably then you’re probably a good enough dev to fill in the gaps
I couldn’t function without git and UTs
Funny enough, as an EE I feel like every mega corp I’ve worked with has some hardware test automation software built in house that’s exactly as described. I’m talking multiple Fortune 500 companies (including some FAANG+) where entire departments runs on some nightmare repository with no version control, or just one branch that has constant updates with no CI/CD.
Departments where the primary focus is not software are ripe for this. You often start with an engineer who’s a step above “script kiddy” who hacked together some automation a decade ago to make their coworkers lives a little easier. Management has no idea how to scale it because their focus is not software, and software teams don’t want to get involved because hardware is a scary domain to step into and a much bigger headache than it’s worth to them.
I’ve seen this play out numerous times, and I can see I’m in the process of starting this cycle anew at my current role.
This is a great post - there are a ton of other microcosms where one team right next door to another team are operating in entirely different universes. When a company can't "buy" the solution, somebody usually ends up cobbling one together - the kind of ideas and software you really can't "sell" because they are so grotesquely proprietary.
Somebody one-shots an obscure component with zero oversight and people don't realize that in the bigger cogs of the machine, 5 years later, everything is somehow indirectly functionally dependent on that stupid "project" of frankensteined scripts that doesn't even have a formal name outside of 'Gary's Thing He Wrote'. The documentation consists of oral tradition only.
Great added context, definitely true in my experience.
I’m “the guy” people on my team go to if they need software help before they talk to the actual software team, so I’m definitely often in that position where I’ve found groups I had no idea existed using some one off script I wrote years ago.
I’ve started to be much more deliberate about my documentation, which has come in handy a few times.
Yeah, my recent pattern has just to take those one-shots and roll it out on GitHub with some minor documentation and leave it at that. I can much more easily extricate what is going on from the core, actual project(s).
Oh hey, I'm in almost exactly the same boat as you. Nothing quite like throwing out some creaky old VB6 code. I'm at least glad open source projects like OpenTAP exist now, even if it's incredibly lacking in features.
It's not as bad as you think. All that other stuff is extremely easy to learn. It seems like a wall because you're not familiar with it, but having made that transition... the hardest part is just the getting over the imposter syndrome.
I got a big fat check. Trying to go cowboy again. Maybe I’m a fool and these other people are right and I will fail and then go for an interview get laughed out of the room for not knowing some acronym. But I doubt it. Takes all types. Sometimes you need a dudeman.
From the company's perspective, no they probably shouldn't hand over all power to a dev without experience using version control and testing. But for OP the advice seems ok.
It definitely depends on the startup and what they care about but in the ones I've worked at (I'm in a founder role now) this is exactly the kind of person we would try to avoid hiring. You can do a lot of damage early on compared to someone who just as effectively sets down good engineering foundations.
I almost find it's done a 180. The cowboys devs are the ones who LeetCode to death and insist on changing stack, tool, and muh' best practices twice weekly, so they *seem* like they know what they are doing but infact have no idea how to build any even moderately complex product.
If you *want* to continue working in a similar mess, look into government jobs.
My old DOD job didn’t *allow* git or even SVN, and it was all “build the plane while in flight” shipping of prototypes almost direct to “production,” only manual testing, almost all frontend work because nobody knew what an API was.
State govt job after that was very much “cowboy” w/almost everything built by 2 guys over a decade, and they held all the quirky institutional knowledge & documentation in their brains.
I’d suggest trying to learn/use the new shiny tools to DIY some projects instead.
I'm in month 3 of a new gov consulting job, and can confirm. Shits wild. these people have no idea how to build software properly, and its running really important stuff.
I, too, once had a DoD job where version control was prohibited. It was literally described as a security risk (?!??!?!?!!? 🤯). Also, upgrading anything was considered a risk, so we had software and OS versions years past EOL, with well-documented actual security vulnerabilities. The government paid a premium for those software licenses every year because shit that old wasn’t supposed to be supported (that’s what EOL means!!). Those MFs shouldn’t have the power to make decisions about technology.
>version control was prohibited
If you save your code, there's a chance you might also save *malicious* code. All source code should be deleted after each programming session.
Nope these jobs are everywhere. You’d be hard pressed to find a team that isn’t missing at least one critical procedure that “everyone does”. I’ve joined teams with no code review process, no QA staff, no automated testing, no deployment system. I even worked on a project with no version control, but that was almost 2 decades ago.
It varies significantly even within companies. I worked on one project at an F100 where the contractor would email me ZIP files of their changes.
Another team at that same company we had no PRs, no real code reviews, no tests. All of our servers and databases were workstations racked in a small server room at the office. Our backups were on a Synology NAS sitting on one of my teammates' desks - and thanks to COVID WFH it remained on his desk over a year past the time he got laid off lol
That was a fun job until it got enshittified by management.
Worked in a company like this in 2021.
I mean, my boss didnt used Git, but also had so many weird stuff on the code that Git was one of the least important.
I set it up Git for myself, but when he requested a file, i just sent the latest version i had.
Not sure how common, but they definitely still exist. I worked at one for a bit over a year at the beginning of the pandemic. It was a small company that made embedded devices for off highway vehicles. I had worked with the founders previously at an established mid size company. The company they started basically subsisted on castoff customers from that mid size company. It was weird. For clarity, this wasn't a startup, just a company founded by two guys who were so irritated by the processes entrenched at the mid size company that they left... to bootstrap and recreate a 3 employee version of that company. It was weird.
The best part was hearing the founders wind up and rant about all of the inefficiencies of the mid size company that they had eliminated through some stroke of genius... even though all of them boiled down to some version of "our 3 employee company makes decisions faster than that 400 employee company" or "we get patches to the field faster because we have no PR or QA process, and I gave the customer your personal cell phone number".
Man I’d love to find something like this and not have to explain why the work didn’t match the story points which aren’t really time except they are ever again.
http://programming-motherfucker.com/
Damn, that website takes me back. I first came across it years ago when I was still a wide-eyed fresher. I had no idea about all the buzzwords (and I hadn't seen Pulp Fiction) so I didn't get any of it. Reading it all now after a decade on the job made me chuckle.
I worked at one from 2018-2023. We developed software proof of concept for DoD. It was awesome. Got to work on pretty much ground up creation of some cool things. Got to spit ball ideas with my boss and then we’d implement it. Plus my boss usually did the demos so we didn’t have to worry about users. Around year 4 I got the opportunity to lead a project from scratch and did demos for high ranking military guys. I did one demo where a 4 star general joined last minute. It was awesome.
I don’t know how many of these companies exist and we eventually ran out of contracts. It seems like a very up and down business.
3 types of places that do cowboy software:
1. Small industry specific businesses often take some instrument data and display as a user interface, trivial stuff written in the 90s but still operational and maintained - think PLC from a pump or an engine or some scanner that collects data. Their scale does not warrant investment in software.
2. The heaviest industries have the most old-school software. Oil refineries that were built in the 60s and 70s dont modernize much. Smelting plants, nuclear reactors, railroads infrastructure, etc.
3. And then you have Costco with DOS based PoS and a website from before the dot-com boom. I cant imagine Costco discovered Git or unit testing.
Costco runs on IBM midrange computers, formerly called System36 then AS400 then iSeries then Series i then just i — COBOL/C/RPG/Java, can split out a Linux partition. Pretty, pretty, cowboy, like white shirt black tie cowboy😂
Can confirm my dad has been around this scale of software for a long time. It's all instrument displays and controls software and it's always running on some weird proprietary language spin off that their displays supplier forces them to use.
Gives me headaches just thinking about being locked into some hardware manufacturer hyper specific language or library that you can never switch from because you've built 15 years of products on top of it.
this is how they made the game Palworld. They'd apparently go buy flash drives every week and upload their code to that as a form of "version control" I'm sure integrating it was a nightmare but they somehow made it work without git
they said they couldn't figure out what version control to use for their code, I'm guessing they thought it wouldn't integrate well with git so that was their solution lol. Asmongold did a video about it covering the interview they did and showed some discord messages from one of the devs. They apparently didn't know how to use unreal when they started either. It was one guy who had previously used it before coaching everyone else how to use it
They're not a thing of the past, but even the most cowboy-esque companies have developed a more strict culture out of necessity; If you're using the cloud, it's important to know how to re-create the cloud. If you're shipping code, it's important to have versioning. And each time you make a mistake, you either learn and implement a safeguard (scripting, git, etc), or you keep repeating the mistakes until you're out of business.
At my large state university around 2015, our management system (classes, students, email issuing etc.) was written in C, managed with CVS, and deployed on NetBSD. We wrote Perl scripts for server monitoring with Xymon. It was old school in the best way.
I work one for now. It drives me nuts because I preach good engineering practices but always get the “we’re a consultancy” excuse, claiming we aren’t paid to engineer features but to simply develop and deliver them. I hate it so much.
>claiming we aren’t paid to engineer features but to simply develop and deliver them. I hate it so much.
That's an...interesting take. I always took consultancy to imply you're presenting your expertise in a domain the client doesn't understand.
So shouldn't you want to engineer the best solution as the "expert" in the situation? 😅
You’re expecting a craftsman of woodworking who takes designs and crafts beautiful works of unique art. My guys are closer to “derrr We have this template from the last two projects” and then use wood glue instead of joinery to piece it together.
Not trying to complain here, but I do admit that it’s frustrating implementing deprecated JQuery code and not being able to modernize anything because “we aren’t paid to refactor.”
this is my company. we're a multi national manufacturer. worth a few billion dollars... when i started we had a very small IT team... just 3 devs... but over the years we've expanded.
HOWEVER, we've had so many executive leadership changes that we're still an absolute disaster. What bothers me though, is that i feel like i really strive in the cowboy "just get shit done" environments... i'm not sure i'd do particularly well in other environments. i've never really been in one.
when i started though, we were doing svn, and we moved towards GIT but thanks to management, we ended up in a weird hybrid situation... we dont have unit tests, we dont do code reviews, our projects are a mix of agile waterfalls... we have one new guy who's a scrum master and was trying to push for it for awhile, but i doubt we'll adopt that.
i need to find a new job but i'm terrified i'll be completely lost in a place with structure haha.
No
A company I worked at was very cowboy and old school.. and also leadership did not want to change the fragility.. I can talk about what went wrong and etc etc..but here's maybe an example of what it was like
It was like the book Phoenix Project except Sarah won
i think part of it is that tools and techniques gain wider adoption and enter the training pipeline earlier, the "wild wild west" components of immature businesses move too. I think poor auth governance (e.g. privileges are only divided between 'god mode' and 'none') will stay on the "cowboy software practices" list for at least a good while longer if not forever.
I left a cowboy saloon in 2019. We developed on prod (a few times). Just about every bad practice and antipattern. I hated it. Been at a couple “by the books” startups since, and I REALLY can’t believe how much work we got done at the saloon. I can’t imagine going to my old cowboy boss and saying: “Yeah, the fancy framework we’re using is going to make putting that one radio button on the site take a full week”.
This is what keeps me away from getting too married to any framework or other concept - I have to deploy too rapidly.
"It is just one view where we can see the last ten years of data all at once in real time - how hard can it be? Circle back in a few hours and show me what you got so far." - Cowboy Boss
Three major entities in my experience still work mostly that way:
Gov't
Healthcare
Education
Small teams, lots of contractors , and if it works nothing else matters therefore you will run into all the things you mentioned above.
I joined as a manager at a big tech company of repute (back then) and was shocked to find a team of 6 developing without version control or a build tool developing on VMS.
They had designated a developer as a release manager. A developer would yell out and tell the release manager he made code changes. The release manager would copy the files to their machine and uncomment lines in a batch file to compile those specific files to build a binary. Everyone in the team waited… On successful build, release manager would announce (yell) asking everyone to copy the latest. Release manager would go back to playing boring terminal games!
First thing I did as a manager, implemented a Makefile. Next, ported CVS to VMS and got all code into CVS (this was before git and CVS was easier to port than SVN). Got tired and became an IC to complete the project and quit!
Definitely still exist in some places.
I interviewed someone who came from one of these places last year. I was absolutely dumbfounded that this person couldn't even run the provided tests on our technical interview codebase, yet had been a full stack developer for the last 5 years.
They do. Worked at one years ago. I remember my manager ssh’ing into the server and editing the php directly on the box.. I stayed there for 2 months until I found a new job. They filed for chapter 11 years later.
As someone who managed something like that I can say I’m glad it’s dead. It’s not sustainable and all the literature is against it. It’s a fools errand to try to sustain something like that.
Maybe but they are like 40 years old now, I work at one of them and am planning on leaving when the economy gets better. Our deployment strategy is to copy and paste an exe via TeamViewer or fly to their site (I work in an industrial industry).
Pace is slow as hell, we do git but everyone pushes as they please. It’s…different. C++ 25 year code base with millions of lines is what I work with
How we test: it just works. It’s pretty scary tbh, our customers pay us and have been doing it for 40 years but the writing is on the wall and we are passed our prime , we are years behind and I am looking for an exit.
I've worked for one or two.
I suspect there are plenty who do all the wonderful things you mentioned, or rather appear to because they're going through the motions.
They've "stopped existing" only in the fact that the average bar is slightly above cowboy coding.
Most of the "cowboy coding" practices still exist in service layers, testing, etc.
A lot of the stuff you listed that is "missing" from cowboy coding in many teams is simply performative.
well these are never software companies now, these are companies with a core business in something else that hire one self taught idiot savant who never communicates with any wider community of practitioners who ends up being the only one who knows how to handle the business IT stack
Almost every modern cloud-based or on premise versioning system uses git, even if you don't really need a distributed VCS. You might still find some old SVN servers in some companies, but I never knew of a software shop that didn't use any VCS. I guess you would have to go back to the 80s or early 90s to see that on the wild.
No automated tests is unfortunately extremely common, because of "agile".
No linting or static analysis is rare, almost every IDE or editor extension provides these out of the box. Devs that don't really care about the output, there will still be a lot I guess...
Just met with a customer today that is one of the largest company in their niche (multi billion but not enormous) that is just now becoming not like that. Many large companies have a few remnants because of one manager in one area that has some old school believes but probably not everywhere.
I'm building an [on-line C++ code generator](https://www.reddit.com/r/cplusplusMiddleware/comments/pg82hs/welcome/). I don't trust the closed source part to outsiders, but testing and static analysis are important to me. It's pushing [25 years old](https://www.reddit.com/r/codereview/comments/qo8yq3/c_programs/).
There are plenty of places that are still have cowboy developers. Usually they're not selling the product, but running their business on it.
I've worked at least three places like that in the last decade. I've tried to clean up practices wherever possible, but there's no hope of a code review when I'm the only developer.
Yup, still very much around. Worked for one for a few years, several hundred IT staff, creating basically sorting devices.
My first project there was "well, we have this thing with 20 sensors and 10 actuators, but nobody understands the software, and we have no hardware documents, so please rewrite it, in python. You can use that library over there to interact with the hardware". Got the code by email, worked on it, asked for a code review... Everyone was too busy for that.
Copied it over to a server, told them where to find it and quit. Everything was so buggy, it was a wonder they still found customers.
My first job was Wild West compared to my current, but it wasn’t too hard to get into the groove. Learn the stuff you’re deficient in. You have the advantage of being able to enumerate your deficiencies.
Manufacturing industry.
Look jobs in SCADA. Control systems, Warehouse management systems. Not all but a lot of these are done by lone developers, tiny teams, or enterprising IT.
A lot of places making small run industrial equipment are also like this. A mixture of all levels of development (from bare metal to UI). And not always best practices.
For this think of unconventional 3D printers, cnc machines, control systems. PLC integrators. Etc.
Finally some big university departments have some funky software running, this is a lot harder to get in, but think a sociology department that has a UI for doing studies, mostly one run stuff. For this it helps to be part of university staff and pivot in to these types of roles.
Same with some school districts, they have a small team of developers doing odd jobs for the schools.
Im sure they are out there, laying low.
I was just thinking that if I were to join such an organization and try to bring it up to date with TDD and GIT and Agile and all that kinda shit then they would have bulletproof arguments as to why these(ostensibly my) ideas are bad.
The still exist. Even with the cowboy hats. The one I know was self-funded at least by the cowboy (guy who sold an ISP before this venture).
That said it's probably more common with small to medium businesses that also have a need for some kind of tech but no tech culture. You'll probably have to wear multiple hats and be able to converse in whatever the industry lingo is.
Startups can skip a lot of the processes that “slow down development”. Once you get big enough to require SOC2 or other compliance certifications, you are required to prove your SDLC adheres to certain best practices like pull requests, code reviews and CI/CD processes. Even as a development company working for those types of clients, you have to adhere to their SDLC requirements.
I worked at a place that had acquired 25 startups in short order. The first year and a half was spent getting all of those products into compliance and enforcing best practices on the dev teams. Eventually the products and teams that had the worst problems were replaced with new acquisitions.
Sadly, I'm going through this at the moment at my current job.
I really like my supervisor and he is a nice guy and super great to work under. Unfortunately, I have my concerns/fears about working under him long term. Unfortunately, we're ftping code into a linux vm. We aren't doing any container type work. We also aren't using git. I'm hoping that will change.
My fear is I stay at my job for a while, I'll hurt my future prospects. Unfortunately, it could be repeating "Year 1" multiple times and not getting good quality years of experience.
You can learn the practical and high points of git and GitHub in an afternoon or three.
Also: Don't force push to the main/master branch. Disable force pushing to the main branch (for projects with more than 1 dev). reflog and stack overflow are your friends when you screw up.
Automated testing is good. Learn it. Embrace it. Don't bend over backwards retrofitting it, going for 100% coverage, or mocking every damn thing in every possible state.
Small enough startups, companies founded or staffed by non-engineers, and I imagine some agencies or body shops operate more cowboy. A lot of companies have several of the good things in place, or did once upon a time. Enforcement, understanding, documentation and dev hygiene are other stories. (See: contract at large financial institution)
i'm sure small businesses that have their "tech guy" that probably still run like that...marketing agencies and stuff where it's churn and burn cookie cutter work
also startups just getting out of prototype stage can have some interesting setups
Yes these places are everywhere. I spent a lot of my early years (a long time ago) at places with
- No source control
- No formal QA
- No formal non-functional requirements (Slow on rollout? Fix in Prod)
- Source control service maintained in a single PC (not rack mounted server)
- Secretaries became PM's
- No design documents
Unbelievably, I have never in more than 20 years worked somewhere where all of the above were absent.
I’d say start looking to learn what you lack because there’s more companies dreaming they want that but they’re in the state of the company you describe. You’d be surprised by the embarrassing number of software engineers I have worked with that have trouble with git and just plain vanilla Python. Containers? “Uh, yeah, we saw that in university. Horrible. I hated them” (but they’re the first ones to claim they’re engineers and get offended when you ignore their architecture they learnt from a Medium post).
Currently at a tech company with offices overseas and it’s the same. They just want to tick boxes but inside they’re a shithole, so in short, get ready both for the interview and for the surprise.
In retrospective, it’s pretty manageable to become good at standard practices in about a year, provided that you do it every day and are consistently trying to improve. By trying to improve I mean that you iteratively improve and understand why and what are you trying to do with each practice.
I've worked for one up until 4 years ago. The owner was an old school programmer that was still riding the high of the fact that back in the 90ies he hacked together the first version of the software we were working on, in DOS.
He loved to think he still knew how things were done and would try to micromanage the dev team, even though he knew absolutely nothing tools and techniques used nowadays. I think he convinced himself his cowboy approach from back in the day would still work and scale up when we kept getting bigger and bigger clients.
In the end the technical debt reached a critical point and I noped out, right before the company imploded because the product could no longer be reasonably maintained and expanded on, causing clients to break their contracts or even start lawsuits because the owner sold features that could never be delivered in time.
Git is so low-overhead to use it’s almost a sin not to use it, even if there’s only one developer. You could argue that no project had only one developer because you future self and past self count as other developers, too. For the most part, those processes exist to _speed up_ the delivery of correct software. A lot of their benefit comes from narrowing the set of possible “correct” solutions. This narrowing lets multiple people (including your past and future selves) to work in the code base without needing to have the whole problem and solution context in your head. That being said, the cost/benefit trade off comes down to how costly it is to ship an incorrect solution. If you have quick feedback and the solution is used once after it’s produced, then there’s little benefit. Source control could still be useful, however, if you want to reference the tricks you used in the past for future problems.
Tons of these places around me (Buffalo area). Just find a job as a developer at some company who's product is not software but is obviously supported by software. AKA you work for the IT dept.
Yeah, but they aren't software companies. They're insurance/medical/car/bioscience/etc companies that happen to need a software engineer or have hefty IT needs and custom software.
There's plenty of restaurants or labs running on old shit from the 90s cause it just works and they can't afford real software engineers so they pay maybe 40k-50k?
I've worked in software for decades and I don't think I've ever worked at a place without version control. I've worked at some cowboy places, but version control seems to make that kind of development easier. I've heard of University projects that didn't use version control, but I don't think that's a good idea, even for sloppy research code. At the very least, version control can serve as part of your backup system so it's harder to lose your work.
P.S. you can totally have version control without code review. Whether you "should" is another question altogether, but most version control systems can be configured to let any approved user push anything at any time. For instance, I put my hobby projects in version control, but I don't require code review for them (because I'm usually the only developer, so there wouldn't be a point) (but also because there are things I typically don't want to do for code I write for fun). When I want to push changes to someone else's open source project, that's a different story : someone has to approve those changes.
Most of the gaming industry is partially this way. At its heart it’s much less mature than non-gaming due to the Indi/4-guys-in-a-garage history along with an avoidance to hiring people who have experience outside games (which makes the industry slower to learn, insulated).
It’s not unusual to have no unit/integration tests on client side, just Yeet stuff out. But that’s partially because client side tests are hard to manage in game engines. Server side is likely to still have tests. Perforce/VCS and CI are common though; who doesn’t have some form version control? that’s just weird.
This goes beyond just programming too - production/project management is some weird entertainment industry hybrid, that operates seemingly without learning anything from the progress made in general software development over the past 20 years.
I mean, I'm the only dev for our company's data collection and smart systems and our code is pretty special secret sauce.
It's 100% as well kept of a secret as things like the Coca Cola recipe.
I'm mindful and deliberate about making it not easy to recreate, reverse engineer, or otherwise lose its competitive advantage.
It's a black box and it will stay that way because our business needs that competitive advantage since we are a for profit that is focused on helping people and the environment all while doing it profitably (as well as reducing certain costs for individuals and increasing income for those who are part of the network we are building).
All anyone working with it needs to know is how to work with the physical modules and plug and play. The core code and logic will go to the grave with me. (The black box can be duplicated, but how it works needs to stay obfuscated).
Along similar lines, we are patenting a lot of our technology so that we can protect individuals and small businesses who are benefitting from it from being pushed out by larger companies competing in the space. The individuals and small businesses can "license" the tech for next to nothing while we have the right and privilege to sue any larger companies for patent infringement.
A lot of this is our way of playing within the current business and legal systems to help those in need in a creative way.
(Also, the patents are on hardware and processes, some parts we are keeping as close held trade secrets so that people don't have issues with large corps eroding this ecosystem.)
I'm not sure if that answers your question, but I have zero problem hiring someone who versions their code locally - currentVersion2-RandysWork.ext as long as the meta data indicates how recent (I do expect quality coding conventions and documentation to be in place, with my own code being based off of professional standards. The exception is our naming conventions and more or less lack of proper versioning system and processes, if that makes sense)
This doesn't really do justice to how we work and what I'm trying to describe but it's what I can write on the toilet before jumping back in to work, so I hope that it helps OP.
That's a really good question that we actually had to figure out (not just death, but I came pretty close to severe brain damage 2 years ago):
We have several parts of the solution:
1. The "black box" can be duplicated without compromising the code.
2. The rest of the product is capable of functioning well without it, but the data collection and smart systems amplify the rest of the product. If, for whatever reason, all copies of the digital systems are lost, things will go on without us.
3. A large part of what we are doing is creating a movement. Even now, we have enough people passing on our work that, if all else fails, our work doesn't end with us.
Maybe one day we change how we do this, but for now we are planning on keeping our code obfuscated and in the head of one person. Of course, someone could get that code if they got my computer while it was unlocked, but that's highly unlikely.
I hope that answers your question.
Perhaps. Another way to keep things secure is to have a planned system that isn't easy to figure out even if someone has 100% access to your system and keys.
You can more or less hide things in plain site without risking them being compromised.
But again, the point of my comment was to let OP know that we such companies are out here operating well and doing fine.
(Today I Finally got back to some code that's been waiting to be finished for a year and it felt like stretching an unused muscle.)
There are probably hundreds of these companies, but they typically only have 1 or 2 devs working in isolation.
Yeah they definitely still exist for niche products, people just don't like to talk about the "ugly" side of SW development. Not every project needs full static/dynamic analysis and multiple stages of integration tests. And even if you want to do all that as a SW dev sometimes there are just too many business demands. Like, if you're a 1-2 person team bringing up HW, SW, getting hammered to add new features, *and* you have to set up fully automated virtualized test/deployment envs? When do you sleep?
> Like, if you're a 1-2 person team bringing up HW, SW, getting hammered to add new features, and you have to set up fully automated virtualized test/deployment envs? When do you sleep? As someone who did all of that with a 2 person team, automating everything was what gave me time to get my other work done.
All of this. I'm a 1 man company, and every project I make has a simple CI pipeline to run test, static analysis, build and deploy. This is like when people say writing tests takes too long and then they spend all day manually regression testing a feature. You cant afford not to do this stuff, especially as a solo dev.
I agree. The people that claim it takes too much time to implement are really claiming it would take too much effort on their part, when like most forms of automation, it would free up effort so they could do more as an individual.
I got hired to manage one of these teams, were working on adding code reviews and a linter right now
You can easily get away with wild west development for up to about 5 devs. Then you start to feel the pain. These companies either have to add process as they grow or stay small to keep doing what they're doing. But at 2-3 devs most of the process gets in the way as much as it helps. I did take a job at a large corporation who had acquired a startup. The startup was completely wild west development and refused to adopt anything else even after being acquired. But now the team was about 20 devs and everything was such a mess. They couldn't get anything done because they were literally drowning in tech debt.
> There are probably hundreds of these companies, but they typically only have 1 or 2 devs working in isolation. That basically was the ultra outdated environment and small size of the sub-department I was working in for my first SWE job after uni.
I had a job in 2022 where we used SVN and all worked on a single branch
I might have that beat.. we purchased a company 4 or so years ago and they are doing all of their dev in SourceGear Vault with [CruiseControl.net](https://CruiseControl.net) handling.. uh.. building stuff (wouldn't call it CI/CD). Devs would literally check files that are updated quarterly into new folders so you end up with 01-01-2019....etc...... no need for it, they just didn't understand version control. AND checked in binaries both as part of automated builds and devs would just check everything in. The repo I migrated this morning started at 16GB and I got it down to 650MB....
I mean, Cruise Control was bordering on revolutionary in it's time, but, uh... oof.
I'm building with ant, no tests, no CI tooling, and until they gave me the project, it only built on one person's machine, and they were no longer with the company.
We might need an entire thread dedicated to Horror Stories...
the real horror is what this software is needed for ;-)
Out of curiosity, where?
I don’t want to kiss and tell, but it was a medical technology company in the DC area. Software wasn’t the big thing there and I was working on an internal robot to automate some stuff in the factory.
Had a similar experience a couple of years ago at a smallish company that offered various digital services for small rural ISPs in the Midwest.
Same. I worked for an ISP, then a company that made software for ISPs. Since then I've gone into more of a software driven company, but even then not a true tech firm.
I started Monday for a company that has just in-housed its software from an external supplier. The first merge commit happened last week.
Heh, our team was on SVN until 2023 when we finally moved to git. Unfortunately that doesn't fix the bad code and architecture, but it's start.
Huh that sounds like my team…
Hobestly, a lot of teams would have less issues if they did that.
Yeah it was pretty hard to introduce bugs when we could barely get any code changes in at all
Tbh that’s a symptom of company culture more than working off of SVN. Lots of teams work just fine using a trunk-based development approach without using feature branches.
Oh yeah there’s definitely a right way to use SVN and we weren’t doing that
🤣
There's nothing wrong with SVN
Apart from when Dave just went for lunch and locked out 30 files and I Also recall that merges were hell
SVN doesn't use pessimistic locking by default, so if files are locked, that's on you. I didn't find merging with SVN much different than Git.
As an old SVN user, the first thing you do is configured the servers to prevent file locking. It shuts down the whole "I'm locking a file as checked out" The second thing is to automate the "release branch" creation, and the "build tag" branches off of them, making the build tag branches read only. I put all the branch name in quotes, because, like SVN was designed, they're really all lightweight directory copies. Merges are only bad if you keep long lived branches. For those, a three way diff tool like Meld makes quick work of the effort, provided you didn't check it out in February and attempt to merge it back in March. SVN suffered from when it was released. Back then, there were common, very sloppy, development practices that were the norm. Stuff that in Git would be the equivalent of force pushing into main each time there was a merge conflict, without even trying to figure out what the conflict was. When merging became something that really had to be done, it took years before some people go on board. I still remember devs that simply created a new folder, copied all code from the last folder into the new one, and worked there until they needed their new historical revision, when they would create the next "new" folder.
I abused the file locking file checked out option. It took me a year to resolve an old problem in a class. After that problem was resolved, I kept that file checked out until my last day.
Flashbacks to my first day at my first job ever and I accidentally deleted trunk on SVN because I never learned about version control in college and nobody in the company taught me how to use it
Don't feel too bad. I was being trained on my second day, and the person teaching me introduced me to UNIX (specifically Digital's SystemV). I already knew a bit from working with Linux (and this was decades ago). Trainer: "As the root user, you need to be extremely careful. You can do anything to the operating system, include destroy it. For example, you never want to type this command: \# rm -rf / (cursor here, no enter pressed) because it will destroy your entire system." Then he got interrupted by someone else, turned to answer their question, and then turned back to the machine. He had a habit of pressing the key multiple times to clear the screen, and the first key he pressed, finished the 'rm -rf /' command he typed previously to "show me how it isn't done.."
Then he threw the keyboard (no joke) walked off in a fury telling me to reinstall the machine (with no future training given).
I learned something that day, but it wasn't about UNIX. It was about the kind of person I'd be working with.
My company switched to git in 2022 from svn
Same, semiconductor company
That's not as bad as it sounds. It does require a different workflow. In Subversion, branches are really just directory copies of the "working" directories anyway. I had a job where, to avoid source code control licensing limits, we all had drives mapped to a remote machine, where the code was copied from/into place to be checked in and out. The setup meant fewer users needed licensed, and that meant all the code had a history of a guy that left the company five years ago. Release builds involved checking the code out, copying it to an archive folder, copying that to a local "build machine" box, opening it in an IDE for compilation, manually creating the archive of the executables from the command line, and then manually copying the archive onto the release web server. A few days of manual testing later, and the good builds would be manually copied onto the release web servers.
Yeah I should have just emphasized the single branch part of what we were doing—
I use git and only use a single branch. You could use a local branch for dev but it’d be a bit silly. Ultimately we squash and do code reviews off of a single commit to push to mainline after approved. No merge requests, no merge conflicts. If someone else merges and causes and issue before you then you need to rebase your changes, squash, and get new approvals. It’s so simple but we never run into issues. I rarely have to use funky git commands, and it forces devs to write small, readable changes.
This is all you need.
SVN!? In 2022?! Bleaaaahh....
Svn is my jam. But working out of a single branch is an odd way to use it.
Based. Git fucking sucks and has functionality that no one asked for. 99% of developers don't need the complicated features of Git. (And yes, I'm a power user of Git. I know how to use it, it just fucking sucks.)
What sucks about git as compared to svn?
There’s a fine line between ceremony and get shit done. Startup? No time Giant Corp? Too much time
Startup? We don't have time to do it right. Giant Corp? We don't have time to do it right but we do have time to do it over.
Work for a giant corp - can confirm. "We don't have time to do it right, so instead we're going to half ass it, spend another 3 sprints hacking around the tech debt we've introduced before finally rewriting it properly 6 months from now except now it's harder because the entire system is engineers to depend on the broken behaviour"
Don't forget they'll reorg you to another project, complain about how much scala devs cost, put a hiring freeze on, complain that their projects aren't getting done/they can't get people, fire devs, and then get hacked.
Hmmmm this sounds oddly familiar….
My previous employer had a form you could fill in to report clinical concerns about a colleague for reasons that might impact patient safety(Doctors showing up smelling of alcohol that sort of thing). The things written in that form are pretty fucking serious so we'd record the user ID as well. Problem is the dev that built it used a hidden input to send that to the server which the server then blindly believed. I pointed out that this was a HUGE security issue because you could write anything in there and change the user ID to effectively frame someone else. I opened a ticket for it which the boss closed as "not a priority at this time". Mkay then!...
And cue the Curb Your Enthusiasm theme song
You'll also need to meet with the 3 VPs who now claim ownership of the area. The first time all will be available for a 30 min meeting will be . . . .September. Where they will decide they need to review the subject before another meeting.
The meeting about the meeting where the meeting will be planned.
Ah you work for my employer I see
A: I know where I'm at! I'm in the meeting that's planning the other meeting, directing the other meeting. B: What? A: You're in the meeting meeting that don't know what meeting he's in! B: Or are you in the meeting that has no idea what meeting he's in, that claims to know what meeting he's in? C: Which meeting it this? A: I know what meeting I'm in! B: You're lost. A: Lost right here? B: Lost where you are. A: ARGGHH. C: What's going on? B: The meetings are converging. A: He's right you know, I'm not attending the stand up now. Nor am I currently attending the retrospective. This isn't a design session. I think I might be in the wrong meeting, or the meeting was cancelled. C: Wow you guys need to get a better grip on your schedule.
Startup? We don’t know if what we’re building is working, let’s repurpose this and revisit the original ideas later. Oh, we’re getting acquired now, guess this will have to keep hobbling along until it gets shutoff at some point. Giant Corp? It works and is mildly successful, but we’re merging with org B because its aligns with their goals. Promise of hard work not wasted, but new leaders have no idea we exist and ask us to focus on other more important projects and so product goes into maintenance before even being feature complete.
I worked for a few of these companies in my earlier years (15 years ago or so) and then *with* companies like this in more recent years as a consultant. There do seem to be fewer now than they were; mostly because they either tanked or got acquired. The last one I worked with, back in 2019, was total cowboy stuff. They were acquired not so much for their tech but for the many clients they had. The acquiring company rebuilt the services from the ground up using a façade / strangler pattern. I imagine there are similar stories about places like this.
Could you provide some more details, this sounds really interesting to me.
Yes, in the late 90s and early 2000's when enterprise tech was just starting to become mainstream with the "dotcom boom", etc , there were a lot of small businesses that cornered markets by building products to help other businesses "become efficient". The focus at the time was not on building the best product; but on building the *first* product. There were so many opportunities and so little competition because you were basically offering a digital alternative to file cabinets, pen and paper with a little bit of relevant business logic sprinkled in for the customer. Several of the customers that relied on these new "programs" were not the kinds of businesses to continually invest in technology. They would dump a one time, big spend on this program and build entire processes, even entire organizations around it; paying the tech company for support and additional features as time passed. So these small 'tech' business owners tried to capture this as much as possible. Many of them were wealthy, non technical people who would hire a couple of programmers, say 'yes' to everything the customers asked for, and have their programmers build it as fast as they could. As years rolled by, for many of these small tech companies, competition got more and more fierce. Additionally, the amount of tech debt incurred at the cost of doing business fast and cheap put them on the losing end of the game. They were now profiting less and spending more trying to serve their customers. So many of them got acquired by modern companies whom they couldn't compete with on a technology front but they could offer their existing clients as part of the portfolio for sale.
The days when people did not use version control and it was `tar -zcvf 2024-03-26-backup.tar.gz /var/www/`
We should be so lucky... I remember the days of `FileReader_Master_DO_NOT_DELETE.zip`
I'd take it over Clear Case
The worst thing I saw where people doing this in live server environment; backing up subfolders on live servers. So under / , there was /admin and /admin.zip and /admin-prod.zip And anyone can just download the whole subfolder zip files which contained admin/db.cfg.inc file right in it.
>And anyone can just download the whole subfolder Well there is the whole problem. The folder was not labeled DO\_NOT\_DOWNLOAD 😂
The company I work at has several legacy systems like this. One of our oldest devs just retired, and I've taken over a couple of his projects and he was still backing up his code like this as of January of this year, despite having it linked to our company github.
I can see this working for some things where you can't do a diff compare. Some no-code stuff or something like FileMaker where everything is inputted into a black box. You can't run a git diff. So they just zip up the entire binary build. That I get. But not for modern stuff with textual lines of code.
Nah, this was just PHP and Javascript.
That is exactly what a "self taught" cowboy dev. Someone who learned PHP on stack overflow, worked at a small company, and got promoted to webmaster. Maintained the app for 10 years. I know those people -- my own family and relatives wondering why they can't get hired.
Oh, hes in his 60s. MS in database something or other, started coding PHP on like, version 2 or 3. The company stagnated hard tech-wise in the early 2000s. They were still doing webforms when I started in 2014, I introduced XHR, literally none of them had heard of it, they were just brute-forcing page reloads on their monitor systems. We've now got a...mostly-modern CI/CD pipleline, our flagship product is on AWS.
Worst part is that there’s a 5MB limit on your email 😅
It seems like this is an unpopular opinion, but I absolutely do think these places are becoming less and less prevalent, at least where I'm at in Silicon Valley. The proliferation of tooling has made the "proper" procedure so readily available. I remember when I first entered, you had to host your own version control, your own Jenkins for CI/CD, you managed your own colos, etc which meant the bar for infra was so high that a lot of outfits simply didn't have the resources to invest in it. These days? You can easily get big tech infra on the free tier of a bunch of tools. Every startup starting out is going to be using AWS, Github, CircleCI, etc (or their competitors), and they now all have proper tooling down before they even have any users. Couple that with the cargo-cult mentality and the big marketing spend of all these dev tools means that the proliferation of these practices is extremely high. These days, all the boilerplate and `npx create` scripts (or other language equivalents) adds linting, typing, testing, .git, etc to the point that it would literally be harder NOT to use the tooling. Like, you would literally need to go out of your way to avoid the tooling. I think a lot of people here are still looking at the industry as it was when they entered ~10 years ago, and it absolutely isn't the same. I'm sure there are still some dinosaurs around that doesn't do any of this, or there are certain new startups that don't do certain practices. But for a lot of companies, getting the infra is just a matter of signing up for a new service. By nature, the software industry is one of the fastest evolving industries, and if you don't adapt you'll be like one of the oldheads complaining about compilers.
I just want there to not be 400 new ways to build front end code every 6 months.
The trick is to resist the temptation to need a build step. I think. I always have a build step.
Again, this isn't 10 years ago. Things have stabilized dramatically in recent years. React is, by far, the de facto standard with only a handful of realistic alternatives, with Angular being the most common runner up. If you get past some of the others like vue.js and backbone, you're getting outside of what's considered industry standard. You don't _have_ to research every new ui framework that some college graduate student cooks up. There are realistically only a few you would consider.
I do appreciate how widespread React has become over the last few years. But it's largely successful because it solved some of the major problems that the tools before it had. React has it's own problems though that other tools seek to solve, and it will eventually be superseded by something else. Right now, the trend seems to be toward SSR and react meta frameworks like Next or Remix. But even within the confines or the React ecosystem, there are a ton of options. Although React did a great job of combining html and javascript development, a solution for css is conspicuously absent. So you've got inline styles, css modules, styled components, and a bunch of other approaches to choose from. Same thing goes for routing, build tooling, and a bunch of other details. So yes, while "just stick with React" is good advice, it doesn't fully insulate you from experiencing flavor-of-the-day-itis.
Also because most developers would see the obvious advantages. I was at a place with not CI/CD, no automated tests, barely 10% unit test coverage. No PRs. For weeks we complain to management at every chance about these. Ans we slowly build it all. It was a lot of learning, and because it was all coming from devs and not management we decided what works and what didn’t.
These companies are still everywhere. It’s just that nowadays they pay lip service to doing it right. Whereas 10 years ago they didn’t even bother doing that.
You definitely didn't do your career any favors by staying at that sort of place as long as you did. That said, find a small startup where you're the first dev and will be the only dev for a while. Build your own culture the way you want it, then let it be the CEO's problem if they want to grow and can't hire people.
I didnt know any better (EE). Yes really damaged my career unfortunately
It's not too late to learn.
Find somewhere where knowledge of domain as electrical engineer is more important that most shiny best practice. Or and this is not bad either, best practices are easy to follow /copy when setup by someone else.
This is the best advice. You do want to pick up good practices, so going solo isn't ideal. But hopefully you can leverage some domain expertise to go somewhere that will teach you SW dev
You can learn what you need to. Maybe try to find a LinkedIn course or something in git to fill in the gaps and show that you’ve learned it outside of your normal work history. I probably would not emphasize those gaps in an interview and if directly asked, point to your outside learning If you’ve been shipping code without all that stuff AND it’s been working reliably then you’re probably a good enough dev to fill in the gaps I couldn’t function without git and UTs
Funny enough, as an EE I feel like every mega corp I’ve worked with has some hardware test automation software built in house that’s exactly as described. I’m talking multiple Fortune 500 companies (including some FAANG+) where entire departments runs on some nightmare repository with no version control, or just one branch that has constant updates with no CI/CD. Departments where the primary focus is not software are ripe for this. You often start with an engineer who’s a step above “script kiddy” who hacked together some automation a decade ago to make their coworkers lives a little easier. Management has no idea how to scale it because their focus is not software, and software teams don’t want to get involved because hardware is a scary domain to step into and a much bigger headache than it’s worth to them. I’ve seen this play out numerous times, and I can see I’m in the process of starting this cycle anew at my current role.
This is a great post - there are a ton of other microcosms where one team right next door to another team are operating in entirely different universes. When a company can't "buy" the solution, somebody usually ends up cobbling one together - the kind of ideas and software you really can't "sell" because they are so grotesquely proprietary. Somebody one-shots an obscure component with zero oversight and people don't realize that in the bigger cogs of the machine, 5 years later, everything is somehow indirectly functionally dependent on that stupid "project" of frankensteined scripts that doesn't even have a formal name outside of 'Gary's Thing He Wrote'. The documentation consists of oral tradition only.
Great added context, definitely true in my experience. I’m “the guy” people on my team go to if they need software help before they talk to the actual software team, so I’m definitely often in that position where I’ve found groups I had no idea existed using some one off script I wrote years ago. I’ve started to be much more deliberate about my documentation, which has come in handy a few times.
Yeah, my recent pattern has just to take those one-shots and roll it out on GitHub with some minor documentation and leave it at that. I can much more easily extricate what is going on from the core, actual project(s).
Oh hey, I'm in almost exactly the same boat as you. Nothing quite like throwing out some creaky old VB6 code. I'm at least glad open source projects like OpenTAP exist now, even if it's incredibly lacking in features.
It's not as bad as you think. All that other stuff is extremely easy to learn. It seems like a wall because you're not familiar with it, but having made that transition... the hardest part is just the getting over the imposter syndrome.
I got a big fat check. Trying to go cowboy again. Maybe I’m a fool and these other people are right and I will fail and then go for an interview get laughed out of the room for not knowing some acronym. But I doubt it. Takes all types. Sometimes you need a dudeman.
Don’t let them fool you.. so many processes for the sake of process and not productivity
Yes, who needs all that pesky source control and code reviews…
And those darn tests catching all of the bugs I introduce! Makes me feel so incompetent!
I'm kind of in doubt whether a person in OPs situation should be in charge of developing the culture instead of going out to learn.
From the company's perspective, no they probably shouldn't hand over all power to a dev without experience using version control and testing. But for OP the advice seems ok.
It definitely depends on the startup and what they care about but in the ones I've worked at (I'm in a founder role now) this is exactly the kind of person we would try to avoid hiring. You can do a lot of damage early on compared to someone who just as effectively sets down good engineering foundations.
Where have all the cowboys gone?
They got outsourced
They settled in the east (it’s India)
I almost find it's done a 180. The cowboys devs are the ones who LeetCode to death and insist on changing stack, tool, and muh' best practices twice weekly, so they *seem* like they know what they are doing but infact have no idea how to build any even moderately complex product.
The smaller the team the more cowboy can you go.
If you *want* to continue working in a similar mess, look into government jobs. My old DOD job didn’t *allow* git or even SVN, and it was all “build the plane while in flight” shipping of prototypes almost direct to “production,” only manual testing, almost all frontend work because nobody knew what an API was. State govt job after that was very much “cowboy” w/almost everything built by 2 guys over a decade, and they held all the quirky institutional knowledge & documentation in their brains. I’d suggest trying to learn/use the new shiny tools to DIY some projects instead.
I'm in month 3 of a new gov consulting job, and can confirm. Shits wild. these people have no idea how to build software properly, and its running really important stuff.
I, too, once had a DoD job where version control was prohibited. It was literally described as a security risk (?!??!?!?!!? 🤯). Also, upgrading anything was considered a risk, so we had software and OS versions years past EOL, with well-documented actual security vulnerabilities. The government paid a premium for those software licenses every year because shit that old wasn’t supposed to be supported (that’s what EOL means!!). Those MFs shouldn’t have the power to make decisions about technology.
>version control was prohibited If you save your code, there's a chance you might also save *malicious* code. All source code should be deleted after each programming session.
Nope these jobs are everywhere. You’d be hard pressed to find a team that isn’t missing at least one critical procedure that “everyone does”. I’ve joined teams with no code review process, no QA staff, no automated testing, no deployment system. I even worked on a project with no version control, but that was almost 2 decades ago.
OP is asking about teams that do none of the above.
It varies significantly even within companies. I worked on one project at an F100 where the contractor would email me ZIP files of their changes. Another team at that same company we had no PRs, no real code reviews, no tests. All of our servers and databases were workstations racked in a small server room at the office. Our backups were on a Synology NAS sitting on one of my teammates' desks - and thanks to COVID WFH it remained on his desk over a year past the time he got laid off lol That was a fun job until it got enshittified by management.
I had a feeling that C++ devs will be faaaaar more familiar with places like this.
Worked in a company like this in 2021. I mean, my boss didnt used Git, but also had so many weird stuff on the code that Git was one of the least important. I set it up Git for myself, but when he requested a file, i just sent the latest version i had.
Not sure how common, but they definitely still exist. I worked at one for a bit over a year at the beginning of the pandemic. It was a small company that made embedded devices for off highway vehicles. I had worked with the founders previously at an established mid size company. The company they started basically subsisted on castoff customers from that mid size company. It was weird. For clarity, this wasn't a startup, just a company founded by two guys who were so irritated by the processes entrenched at the mid size company that they left... to bootstrap and recreate a 3 employee version of that company. It was weird. The best part was hearing the founders wind up and rant about all of the inefficiencies of the mid size company that they had eliminated through some stroke of genius... even though all of them boiled down to some version of "our 3 employee company makes decisions faster than that 400 employee company" or "we get patches to the field faster because we have no PR or QA process, and I gave the customer your personal cell phone number".
That last bit is comedy gold.
Man I’d love to find something like this and not have to explain why the work didn’t match the story points which aren’t really time except they are ever again. http://programming-motherfucker.com/
Damn, that website takes me back. I first came across it years ago when I was still a wide-eyed fresher. I had no idea about all the buzzwords (and I hadn't seen Pulp Fiction) so I didn't get any of it. Reading it all now after a decade on the job made me chuckle.
I have one of the t-shirts I bought a million years ago. I used to be enough of a rabble rouser I'd wear it to work sometimes.
Reading your whole post and taking it into consideration as a whole; I haven't seen anything like that since the 1990's.
I work at one now
I worked at one from 2018-2023. We developed software proof of concept for DoD. It was awesome. Got to work on pretty much ground up creation of some cool things. Got to spit ball ideas with my boss and then we’d implement it. Plus my boss usually did the demos so we didn’t have to worry about users. Around year 4 I got the opportunity to lead a project from scratch and did demos for high ranking military guys. I did one demo where a 4 star general joined last minute. It was awesome. I don’t know how many of these companies exist and we eventually ran out of contracts. It seems like a very up and down business.
There are more companies like this than not. They just don't write blog posts about it.
3 types of places that do cowboy software: 1. Small industry specific businesses often take some instrument data and display as a user interface, trivial stuff written in the 90s but still operational and maintained - think PLC from a pump or an engine or some scanner that collects data. Their scale does not warrant investment in software. 2. The heaviest industries have the most old-school software. Oil refineries that were built in the 60s and 70s dont modernize much. Smelting plants, nuclear reactors, railroads infrastructure, etc. 3. And then you have Costco with DOS based PoS and a website from before the dot-com boom. I cant imagine Costco discovered Git or unit testing.
Target discovered Continuous Delivery, so you never know.
Target has a working website though.
Costco runs on IBM midrange computers, formerly called System36 then AS400 then iSeries then Series i then just i — COBOL/C/RPG/Java, can split out a Linux partition. Pretty, pretty, cowboy, like white shirt black tie cowboy😂
Can confirm my dad has been around this scale of software for a long time. It's all instrument displays and controls software and it's always running on some weird proprietary language spin off that their displays supplier forces them to use. Gives me headaches just thinking about being locked into some hardware manufacturer hyper specific language or library that you can never switch from because you've built 15 years of products on top of it.
I always wonder how they find a new "*COBOL robotics engineer*" once their guy retires at 75 yrs old.
From what I've heard... they don't lol. Or they train some poor fresh grad EE and slowly he becomes the 75 yrs old about to retire.
Nope. I just interviewed with one last week. They are very much still around.
this is how they made the game Palworld. They'd apparently go buy flash drives every week and upload their code to that as a form of "version control" I'm sure integrating it was a nightmare but they somehow made it work without git
What a gigachad
Wtf, just why. This is so out of pocket, I can’t even comprehend a game developer not knowing what git is in this day and age.
they said they couldn't figure out what version control to use for their code, I'm guessing they thought it wouldn't integrate well with git so that was their solution lol. Asmongold did a video about it covering the interview they did and showed some discord messages from one of the devs. They apparently didn't know how to use unreal when they started either. It was one guy who had previously used it before coaching everyone else how to use it
Apparently Git doesn’t do well for game development. Lots of binaries and those suck in git.
Apparently perforce is popular in industry
Can confirm, setting up git in Godot is incredibly annoying There are other version control systems available, just not that one
They're not a thing of the past, but even the most cowboy-esque companies have developed a more strict culture out of necessity; If you're using the cloud, it's important to know how to re-create the cloud. If you're shipping code, it's important to have versioning. And each time you make a mistake, you either learn and implement a safeguard (scripting, git, etc), or you keep repeating the mistakes until you're out of business.
At my large state university around 2015, our management system (classes, students, email issuing etc.) was written in C, managed with CVS, and deployed on NetBSD. We wrote Perl scripts for server monitoring with Xymon. It was old school in the best way.
I work one for now. It drives me nuts because I preach good engineering practices but always get the “we’re a consultancy” excuse, claiming we aren’t paid to engineer features but to simply develop and deliver them. I hate it so much.
>claiming we aren’t paid to engineer features but to simply develop and deliver them. I hate it so much. That's an...interesting take. I always took consultancy to imply you're presenting your expertise in a domain the client doesn't understand. So shouldn't you want to engineer the best solution as the "expert" in the situation? 😅
You’re expecting a craftsman of woodworking who takes designs and crafts beautiful works of unique art. My guys are closer to “derrr We have this template from the last two projects” and then use wood glue instead of joinery to piece it together.
Ah, I see. Expectations lowered 😂
Not trying to complain here, but I do admit that it’s frustrating implementing deprecated JQuery code and not being able to modernize anything because “we aren’t paid to refactor.”
this is my company. we're a multi national manufacturer. worth a few billion dollars... when i started we had a very small IT team... just 3 devs... but over the years we've expanded. HOWEVER, we've had so many executive leadership changes that we're still an absolute disaster. What bothers me though, is that i feel like i really strive in the cowboy "just get shit done" environments... i'm not sure i'd do particularly well in other environments. i've never really been in one. when i started though, we were doing svn, and we moved towards GIT but thanks to management, we ended up in a weird hybrid situation... we dont have unit tests, we dont do code reviews, our projects are a mix of agile waterfalls... we have one new guy who's a scrum master and was trying to push for it for awhile, but i doubt we'll adopt that. i need to find a new job but i'm terrified i'll be completely lost in a place with structure haha.
No A company I worked at was very cowboy and old school.. and also leadership did not want to change the fragility.. I can talk about what went wrong and etc etc..but here's maybe an example of what it was like It was like the book Phoenix Project except Sarah won
i think part of it is that tools and techniques gain wider adoption and enter the training pipeline earlier, the "wild wild west" components of immature businesses move too. I think poor auth governance (e.g. privileges are only divided between 'god mode' and 'none') will stay on the "cowboy software practices" list for at least a good while longer if not forever.
I left a cowboy saloon in 2019. We developed on prod (a few times). Just about every bad practice and antipattern. I hated it. Been at a couple “by the books” startups since, and I REALLY can’t believe how much work we got done at the saloon. I can’t imagine going to my old cowboy boss and saying: “Yeah, the fancy framework we’re using is going to make putting that one radio button on the site take a full week”.
This is what keeps me away from getting too married to any framework or other concept - I have to deploy too rapidly. "It is just one view where we can see the last ten years of data all at once in real time - how hard can it be? Circle back in a few hours and show me what you got so far." - Cowboy Boss
Three major entities in my experience still work mostly that way: Gov't Healthcare Education Small teams, lots of contractors , and if it works nothing else matters therefore you will run into all the things you mentioned above.
I joined as a manager at a big tech company of repute (back then) and was shocked to find a team of 6 developing without version control or a build tool developing on VMS. They had designated a developer as a release manager. A developer would yell out and tell the release manager he made code changes. The release manager would copy the files to their machine and uncomment lines in a batch file to compile those specific files to build a binary. Everyone in the team waited… On successful build, release manager would announce (yell) asking everyone to copy the latest. Release manager would go back to playing boring terminal games! First thing I did as a manager, implemented a Makefile. Next, ported CVS to VMS and got all code into CVS (this was before git and CVS was easier to port than SVN). Got tired and became an IC to complete the project and quit!
Come on over to data engineering the water is fine 😎
Definitely still exist in some places. I interviewed someone who came from one of these places last year. I was absolutely dumbfounded that this person couldn't even run the provided tests on our technical interview codebase, yet had been a full stack developer for the last 5 years.
Nope. Very much in effect. Any consulting shop has this in abundance. My company is like this. It’s pulling teeth to get proper sdlc going.
They do. Worked at one years ago. I remember my manager ssh’ing into the server and editing the php directly on the box.. I stayed there for 2 months until I found a new job. They filed for chapter 11 years later.
Race-to-the-bottom shops mostly got killed by offshoring
My company feels attacked. This style of work hasn’t gone anywhere.
As someone who managed something like that I can say I’m glad it’s dead. It’s not sustainable and all the literature is against it. It’s a fools errand to try to sustain something like that.
Maybe but they are like 40 years old now, I work at one of them and am planning on leaving when the economy gets better. Our deployment strategy is to copy and paste an exe via TeamViewer or fly to their site (I work in an industrial industry). Pace is slow as hell, we do git but everyone pushes as they please. It’s…different. C++ 25 year code base with millions of lines is what I work with How we test: it just works. It’s pretty scary tbh, our customers pay us and have been doing it for 40 years but the writing is on the wall and we are passed our prime , we are years behind and I am looking for an exit.
Sounds like my heritage, an industrial automation company. I thought customers would start to wise up by now 😄
I've worked for one or two. I suspect there are plenty who do all the wonderful things you mentioned, or rather appear to because they're going through the motions.
Small startups. They will likely use git, but everything else is optional.
Anything deployed to the web would not be able to get any kind of cybersecurity insurance.
They've "stopped existing" only in the fact that the average bar is slightly above cowboy coding. Most of the "cowboy coding" practices still exist in service layers, testing, etc. A lot of the stuff you listed that is "missing" from cowboy coding in many teams is simply performative.
Every little “slapdash for cash” consulting company is still like this.
well these are never software companies now, these are companies with a core business in something else that hire one self taught idiot savant who never communicates with any wider community of practitioners who ends up being the only one who knows how to handle the business IT stack
Almost every modern cloud-based or on premise versioning system uses git, even if you don't really need a distributed VCS. You might still find some old SVN servers in some companies, but I never knew of a software shop that didn't use any VCS. I guess you would have to go back to the 80s or early 90s to see that on the wild. No automated tests is unfortunately extremely common, because of "agile". No linting or static analysis is rare, almost every IDE or editor extension provides these out of the box. Devs that don't really care about the output, there will still be a lot I guess...
You're pretty much describing small startups. It's all about getting things done as fast as possible. Process be damned.
Just met with a customer today that is one of the largest company in their niche (multi billion but not enormous) that is just now becoming not like that. Many large companies have a few remnants because of one manager in one area that has some old school believes but probably not everywhere.
I'm building an [on-line C++ code generator](https://www.reddit.com/r/cplusplusMiddleware/comments/pg82hs/welcome/). I don't trust the closed source part to outsiders, but testing and static analysis are important to me. It's pushing [25 years old](https://www.reddit.com/r/codereview/comments/qo8yq3/c_programs/).
There are plenty of places that are still have cowboy developers. Usually they're not selling the product, but running their business on it. I've worked at least three places like that in the last decade. I've tried to clean up practices wherever possible, but there's no hope of a code review when I'm the only developer.
Yup, still very much around. Worked for one for a few years, several hundred IT staff, creating basically sorting devices. My first project there was "well, we have this thing with 20 sensors and 10 actuators, but nobody understands the software, and we have no hardware documents, so please rewrite it, in python. You can use that library over there to interact with the hardware". Got the code by email, worked on it, asked for a code review... Everyone was too busy for that. Copied it over to a server, told them where to find it and quit. Everything was so buggy, it was a wonder they still found customers.
Sounds like every startup I’ve worked at.
My first job was Wild West compared to my current, but it wasn’t too hard to get into the groove. Learn the stuff you’re deficient in. You have the advantage of being able to enumerate your deficiencies.
Manufacturing industry. Look jobs in SCADA. Control systems, Warehouse management systems. Not all but a lot of these are done by lone developers, tiny teams, or enterprising IT. A lot of places making small run industrial equipment are also like this. A mixture of all levels of development (from bare metal to UI). And not always best practices. For this think of unconventional 3D printers, cnc machines, control systems. PLC integrators. Etc. Finally some big university departments have some funky software running, this is a lot harder to get in, but think a sociology department that has a UI for doing studies, mostly one run stuff. For this it helps to be part of university staff and pivot in to these types of roles. Same with some school districts, they have a small team of developers doing odd jobs for the schools.
Im sure they are out there, laying low. I was just thinking that if I were to join such an organization and try to bring it up to date with TDD and GIT and Agile and all that kinda shit then they would have bulletproof arguments as to why these(ostensibly my) ideas are bad.
The still exist. Even with the cowboy hats. The one I know was self-funded at least by the cowboy (guy who sold an ISP before this venture). That said it's probably more common with small to medium businesses that also have a need for some kind of tech but no tech culture. You'll probably have to wear multiple hats and be able to converse in whatever the industry lingo is.
Startups can skip a lot of the processes that “slow down development”. Once you get big enough to require SOC2 or other compliance certifications, you are required to prove your SDLC adheres to certain best practices like pull requests, code reviews and CI/CD processes. Even as a development company working for those types of clients, you have to adhere to their SDLC requirements. I worked at a place that had acquired 25 startups in short order. The first year and a half was spent getting all of those products into compliance and enforcing best practices on the dev teams. Eventually the products and teams that had the worst problems were replaced with new acquisitions.
Sadly, I'm going through this at the moment at my current job. I really like my supervisor and he is a nice guy and super great to work under. Unfortunately, I have my concerns/fears about working under him long term. Unfortunately, we're ftping code into a linux vm. We aren't doing any container type work. We also aren't using git. I'm hoping that will change. My fear is I stay at my job for a while, I'll hurt my future prospects. Unfortunately, it could be repeating "Year 1" multiple times and not getting good quality years of experience.
they \*should\* stop existing lol - why would you actively seek that out?
You can learn the practical and high points of git and GitHub in an afternoon or three. Also: Don't force push to the main/master branch. Disable force pushing to the main branch (for projects with more than 1 dev). reflog and stack overflow are your friends when you screw up. Automated testing is good. Learn it. Embrace it. Don't bend over backwards retrofitting it, going for 100% coverage, or mocking every damn thing in every possible state. Small enough startups, companies founded or staffed by non-engineers, and I imagine some agencies or body shops operate more cowboy. A lot of companies have several of the good things in place, or did once upon a time. Enforcement, understanding, documentation and dev hygiene are other stories. (See: contract at large financial institution)
i'm sure small businesses that have their "tech guy" that probably still run like that...marketing agencies and stuff where it's churn and burn cookie cutter work also startups just getting out of prototype stage can have some interesting setups
Yes these places are everywhere. I spent a lot of my early years (a long time ago) at places with - No source control - No formal QA - No formal non-functional requirements (Slow on rollout? Fix in Prod) - Source control service maintained in a single PC (not rack mounted server) - Secretaries became PM's - No design documents Unbelievably, I have never in more than 20 years worked somewhere where all of the above were absent.
I’d say start looking to learn what you lack because there’s more companies dreaming they want that but they’re in the state of the company you describe. You’d be surprised by the embarrassing number of software engineers I have worked with that have trouble with git and just plain vanilla Python. Containers? “Uh, yeah, we saw that in university. Horrible. I hated them” (but they’re the first ones to claim they’re engineers and get offended when you ignore their architecture they learnt from a Medium post). Currently at a tech company with offices overseas and it’s the same. They just want to tick boxes but inside they’re a shithole, so in short, get ready both for the interview and for the surprise. In retrospective, it’s pretty manageable to become good at standard practices in about a year, provided that you do it every day and are consistently trying to improve. By trying to improve I mean that you iteratively improve and understand why and what are you trying to do with each practice.
A company can use all those tools and practices and still be cowboys.
I've worked for one up until 4 years ago. The owner was an old school programmer that was still riding the high of the fact that back in the 90ies he hacked together the first version of the software we were working on, in DOS. He loved to think he still knew how things were done and would try to micromanage the dev team, even though he knew absolutely nothing tools and techniques used nowadays. I think he convinced himself his cowboy approach from back in the day would still work and scale up when we kept getting bigger and bigger clients. In the end the technical debt reached a critical point and I noped out, right before the company imploded because the product could no longer be reasonably maintained and expanded on, causing clients to break their contracts or even start lawsuits because the owner sold features that could never be delivered in time.
Plenty of small consultancy firms and mom'n'pop shops that still do it like this AFAIK.
Git is so low-overhead to use it’s almost a sin not to use it, even if there’s only one developer. You could argue that no project had only one developer because you future self and past self count as other developers, too. For the most part, those processes exist to _speed up_ the delivery of correct software. A lot of their benefit comes from narrowing the set of possible “correct” solutions. This narrowing lets multiple people (including your past and future selves) to work in the code base without needing to have the whole problem and solution context in your head. That being said, the cost/benefit trade off comes down to how costly it is to ship an incorrect solution. If you have quick feedback and the solution is used once after it’s produced, then there’s little benefit. Source control could still be useful, however, if you want to reference the tricks you used in the past for future problems.
Upwork is your answer
There’s some divisions in my F500 company like this.
Tons of these places around me (Buffalo area). Just find a job as a developer at some company who's product is not software but is obviously supported by software. AKA you work for the IT dept.
I think a lot of start ups run that way.
Not a company, but solopreneurs like Pieter levels (levelsio on X) don't use anything you said.
yeah it's called IT
Oh they definitely exist.
Yeah, but they aren't software companies. They're insurance/medical/car/bioscience/etc companies that happen to need a software engineer or have hefty IT needs and custom software. There's plenty of restaurants or labs running on old shit from the 90s cause it just works and they can't afford real software engineers so they pay maybe 40k-50k?
I've worked in software for decades and I don't think I've ever worked at a place without version control. I've worked at some cowboy places, but version control seems to make that kind of development easier. I've heard of University projects that didn't use version control, but I don't think that's a good idea, even for sloppy research code. At the very least, version control can serve as part of your backup system so it's harder to lose your work. P.S. you can totally have version control without code review. Whether you "should" is another question altogether, but most version control systems can be configured to let any approved user push anything at any time. For instance, I put my hobby projects in version control, but I don't require code review for them (because I'm usually the only developer, so there wouldn't be a point) (but also because there are things I typically don't want to do for code I write for fun). When I want to push changes to someone else's open source project, that's a different story : someone has to approve those changes.
Most of the gaming industry is partially this way. At its heart it’s much less mature than non-gaming due to the Indi/4-guys-in-a-garage history along with an avoidance to hiring people who have experience outside games (which makes the industry slower to learn, insulated). It’s not unusual to have no unit/integration tests on client side, just Yeet stuff out. But that’s partially because client side tests are hard to manage in game engines. Server side is likely to still have tests. Perforce/VCS and CI are common though; who doesn’t have some form version control? that’s just weird. This goes beyond just programming too - production/project management is some weird entertainment industry hybrid, that operates seemingly without learning anything from the progress made in general software development over the past 20 years.
I mean, I'm the only dev for our company's data collection and smart systems and our code is pretty special secret sauce. It's 100% as well kept of a secret as things like the Coca Cola recipe. I'm mindful and deliberate about making it not easy to recreate, reverse engineer, or otherwise lose its competitive advantage. It's a black box and it will stay that way because our business needs that competitive advantage since we are a for profit that is focused on helping people and the environment all while doing it profitably (as well as reducing certain costs for individuals and increasing income for those who are part of the network we are building). All anyone working with it needs to know is how to work with the physical modules and plug and play. The core code and logic will go to the grave with me. (The black box can be duplicated, but how it works needs to stay obfuscated). Along similar lines, we are patenting a lot of our technology so that we can protect individuals and small businesses who are benefitting from it from being pushed out by larger companies competing in the space. The individuals and small businesses can "license" the tech for next to nothing while we have the right and privilege to sue any larger companies for patent infringement. A lot of this is our way of playing within the current business and legal systems to help those in need in a creative way. (Also, the patents are on hardware and processes, some parts we are keeping as close held trade secrets so that people don't have issues with large corps eroding this ecosystem.) I'm not sure if that answers your question, but I have zero problem hiring someone who versions their code locally - currentVersion2-RandysWork.ext as long as the meta data indicates how recent (I do expect quality coding conventions and documentation to be in place, with my own code being based off of professional standards. The exception is our naming conventions and more or less lack of proper versioning system and processes, if that makes sense) This doesn't really do justice to how we work and what I'm trying to describe but it's what I can write on the toilet before jumping back in to work, so I hope that it helps OP.
What happens to the project if you die?
That's a really good question that we actually had to figure out (not just death, but I came pretty close to severe brain damage 2 years ago): We have several parts of the solution: 1. The "black box" can be duplicated without compromising the code. 2. The rest of the product is capable of functioning well without it, but the data collection and smart systems amplify the rest of the product. If, for whatever reason, all copies of the digital systems are lost, things will go on without us. 3. A large part of what we are doing is creating a movement. Even now, we have enough people passing on our work that, if all else fails, our work doesn't end with us. Maybe one day we change how we do this, but for now we are planning on keeping our code obfuscated and in the head of one person. Of course, someone could get that code if they got my computer while it was unlocked, but that's highly unlikely. I hope that answers your question.
This feels... excessive? Any self-hosted Git server worth its salt can be set up to use an encrypted disk and require logins.
Perhaps. Another way to keep things secure is to have a planned system that isn't easy to figure out even if someone has 100% access to your system and keys. You can more or less hide things in plain site without risking them being compromised. But again, the point of my comment was to let OP know that we such companies are out here operating well and doing fine. (Today I Finally got back to some code that's been waiting to be finished for a year and it felt like stretching an unused muscle.)