* Cover Letters
* Most test reports
* Lots of docs required by the government
* I'm sure there are more you can think of
So now we can have stuff written that no-one ever writes and no-one ever reads? Hmm...
316 karma · joined March 23, 2018
* Cover Letters
* Most test reports
* Lots of docs required by the government
* I'm sure there are more you can think of
So now we can have stuff written that no-one ever writes and no-one ever reads? Hmm...
The basic workflow adopted by our manager was thus:
1. Discover a bug or get a feature request
2. Pass the task to the development team verbally
3. Developers prioritize tasks based on which ones are more likely to be forgotten by management
4. Approx 20% of tasks get completed
5. Repeat step 1
You might think, with our superstar developer, a workflow like this would be possible. Honestly, I saw him do things (pre-AI) that were astonishing. He would work a weekend and add a feature I thought would take 2 weeks. He created a re-write of our main product and demoed a completely new product using the same hardware by himself in about 6 months. He would take feature requests not assigned to him and just do them before the assigned developer was even finished planning the feature. The sales team would come in with a pitch for an insane new feature idea (like add a Farsi version of the UI) on Friday, the rest of the team would attempt to push back on it, then he would check-in a semi-working version of that feature on Monday. For these reasons our manager loved him and would always ask the rest of the development team why we couldn't keep up. It was demoralizing and frustrating. At the same time, as a company, we were mostly unable to get very simple changes out the door. Most of the insane features we added died on the vine before getting to the customer (but the code would remain polluting the codebase). Any bug that was fixed would reveal 2 more serious show-stopping bugs. New software releases were regularly regressed: they would break one of our customer's use cases and because we never created basic functionality like OTA updates, we would fly a tech out with a flash drive to revert all the software. We worked on 3-4 new products an not a single one ever saw the light of day. Our company github was littered with dead, abandoned, duplicated repos.Basically our superstar developer absolutely allowed our non-technical management to commit software development seppuku. His successes were highly visible, but his failures were not:
1. Clobbering other developer's commits because he didn't know how to use git to rebase or merge changes
2. Copy pasting (not forking) entire codebases to work on a new feature that then got so bloated they were impossible to merge
3. Absolutely no documentation of any sort, not even comments.
4. No automated testing of any sort on any of his code even though there was an effort by the rest of the team to do better testing.
5. Refusal to use the common Docker development platform everyone else had standardized on, many times his code only worked on his machine.
6. He wouldn't fix bugs, he would just re-write the core logic of the feature that had the bug and then he wouldn't bother to remove the old logic.
7. Regular, daily code dumps of 1000-2000 LOC that contained new features that were not discussed by the team, sometimes from casual conversations with a sales person, sometimes completely made up by him out of boredom I guess.
8. Our Linux BSP was stuck in Amber because the only copy of it was on his local machine (allegedly). When asked many many times by the rest of the team to get it in our company repo he would check in something that did not compile and was not even remotely close to what was being used on our boards.
9. Instead of adding dependencies where needed he would take a 3rd party library, chop it up and copy-paste it into our code directly (see point 8).
10. Last but not least just general slop code with 15-20 levels of indentation, no modularity, dirty hacks everywhere.
I think about him a lot when I think about companies going all in on productivity maxxed vibe coded AI. I think that under better management that restricted his impulses and gave him more structure, he could have been a great asset to the company. Unfortunately when let run wild over the company codebase he was an absolute menace and ultimately led to less actual useful work getting done and an erosion of customer trust. I think this might be the reason we are getting two diametrically opposed experiences with AI: it is either going to destroy your codebase or deliver features at an astounding pace, and I think the difference is the actual technical knowledge of who is managing these projects. My guess is that there are a lot of places with middling or non-technical management pushing AI coding that are going to be in struggle city in a year or so and not understand how they got there. "But AI was making us so productive!".I have come to the conclusion that people using AI for coding need to think about it as basically an automated version of the Docs -> Copy Paste -> Stack Overflow -> Copy Paste -> Compile Error -> Google -> Copy Paste -> New feature request from management -> Random internet blog -> Copy Paste loop that most of us do for a lot of the non-logic heavy portions (e.g. API interfacing) of our work with less randomness and more pattern matching or statistics or whatever guiding the process. Honestly, pretty useful, not knocking it.
I do think there is a killer application for AI, which it is already useful for, and that the industry doesn't really promote. That is basically taking a massive amount of unstructured data on a topic and allowing people an easy way to learn from that data without having to read through all of it (which may not even be possible for a single person in their lifetime). This would be a huge boon to humanity alone given the scale of data we produce. I think fundamentally, LLMs cannot take the data that they are so good at summarizing and use it in a creative way, it looks kinda like they can, because they are so good at "borrowing" other people's creative work, but in real-world scenarios where change is constant and the external forces of today are not understood by a model that was trained 3 months ago, they fall on their faces again and again.
I think AI companies know this but cannot admit that this ground breaking (I would argue) technology might only be transformative for one half of the observe->act workflow that would be necessary to replace humans as workers because.
1. It is possible the economics don't work out without replacing workers 2. If they admitted that the only value of their tech was in distilling value already present in other people's creative work, work that the LLMs cannot create on their own, a sane government might force them to pay for their inputs.
Reading this books was a huge turning point for me as someone with diagnosed mild Autism. I think a lot of the things in this books are fairly obvious to non neuro-divergent folks. But for me, it was like a manual on how to handle myself in social situations, a thing that was mysterious and frustrating to me before. I wouldn't say I am now some sort of socialite, but I am far from the days of being being excluded from basically every social group I attempted to be part of.
Wouldn't that just be called inventing a new language with all the overhead of the languages we already have? Are we getting to the point where getting LLMs to be productive and also write good code is going to require so much overhead and additional procedures and tools that we might as well write the code ourselves. Hmmm...
Location: Denver, CO USA
Remote: Remote | Hybrid | In Office
Willing to relocate: No
Technologies: C/C++, Python, Buildroot, ATTiny, ATMega, STM32
Résumé/CV: https://drive.google.com/file/d/1G5zuFuMXbzGVIIIhlLNEi5Mg6wDOQOFM/view?usp=sharing
Email: dkuntz417@gmail.com
Github: https://github.com/GhostWrench
Thank you for your time! Location: Denver, CO
Remote: Yes
Willing to relocate: No
Technologies: PCB design and layout (KiCad), AVR micro controllers (ATtiny/ATMega), ARM Microcontrollers (STM32), ARM Microprocessors (SAM9), Embedded Linux (Buildroot), C/C++, Python, Matlab
Résumé/CV: https://drive.google.com/file/d/1tqwy_AIahBebBIwrj5xs2n20trVVsssW/view?usp=sharing
Email: dkuntz417@gmail.comI can go foraging / hunting right now and find food, not enough to live off, but in a time before land ownership and mass population explosions, there would have been enough... Which... is the entire point of the article. So are you arguing for the premise of the article then?