13 ms·

I'm having similar issues, and i think i found a way out: stop playing their game. Don't make enterprise software. Don't write unit tests. Don't accept pull req

I'm having similar issues, and i think i found a way out: stop playing their game. Don't make enterprise software. Don't write unit tests. Don't accept pull requests. Simply write software for yourself and have fun doing it. Forget refactoring code into modules, just fucking code. Don't worry about deployment with k8s, just copy the Python script to your production folder and run it. Fuck all that shit about git branch naming conventions, or how you're supposed to use an object factory, just do whatever you want in the moment, bit by bit, until your software works most of the time then use it. Forget configuration, just hard code values for now. Don't worry about documentation, just do it. Your expectations, and the expectations of others, are your enemy here. At least, that's what got me out it. I'm still disillusioned with the world but it's manageable if I can realize I'm making a difference to my son and wife every day, and that's what counts for me.

gfosco 6y ago
That's generally an unpopular and unwelcome opinion here, but I agree with you 100%. edit: and i'll happily take those downvotes, they are delicious thank you.
- cyborgx7 6y ago
  you are not getting downvotes because people are disagreeing with you
  - xparco 6y ago
    Stop lying
- 0xdeadbeefbabe 6y ago
  Not on this story. Those other folks are too busy configuring stuff, arguing about curl website/script.sh | sh, and building microservices to feel burnt out yet.
aprdm 6y ago
This! (And wait until you figure out there’s a lot of real companies running like that..) I would say to also work in a domain you care about and like. I don’t like technology for technology sake and never did. I like solving problems and see technology as a tool to do so. I love the company I work for, the people and the problems we get to solve. I love even more when I solve them without the need to write a single line of code.
Royalaid 6y ago
I think this is a natural reaction to advice being over prescribed and totally agree that in your free time you should do whatever it is you want and this is solid advice. BUT I think we should also acknowledge that everything that slows you down in your free time has a reason for existing and most of that is communication or knowledge sharing within a team. Naming conventions, unit tests, and general documentation all exist to help other team members keep up with the pace of changes in the repository. If you're not planning to do something in a team setting or for this to be consumed outside of the work that you do then you don't need these things. But if you want to share with everyone else it's important that you don't totally ignore these things because it will come back to bite you in the long run.
- wolco 6y ago
  The idea is to stop trying to make it easier to share and others to use and just write something that works for you. Kinda like the idea for personal. Why spend so much effort to structure projects so others can use when chances are they won't or you don't care if they do. Work is governed by different realities.
- deleted 6y ago
  [deleted]
makapuf 6y ago
Thats exactly what i did while working on dreaded big data. Got myself a microcontroller, implemented a small arm console and write fucking low level C code optimized the heck of cpu cycles for tiny games, no code reuse, no interfaced, no deadlines, no refacto, no security, no network, no politics. Barely version control (with appropriate "update" commit messages). Kept me sane while doing those things at work.
- ay 6y ago
  +1 on the small 1-2 weekend tangible projects, that you may have wanted to build before, but never got to, they are great for morale. This weekend I implemented RS232-powered RGB LED that is controlled attiny85, which reacts to strings sent to that very same RS232. A gross violation of standard, probably, but it works! It definitely added a lot of joy. I typed “git init” only after I finished the first working version which had a regular One-color LED, and could not yet do blinking :-)
  - BenjiWiebe 6y ago
    For even more fun with low level breaking of standards, bit-banging rs232 is fun and very doable. Don't use timers for timing either, just spin the cpu the right number of times. :)
    - ay 6y ago
      This project actually does decode of Rs232 data, with the special prefix triggering the interpreter mode where you can control the color and delay between the cycles. Only ground and TX pins are used to connect. Oh, and no interrupts - poll for the start bit while running the currently programmed light animation cycle :-) One thing that made the development of it all immensely easier was having a Saleae logic analyzer. Highly recommend it (no affiliation, just a happy customer).
- cblum 6y ago
  Interesting, I’m on the same boat. Embedded systems and low-level coding are my beacons of sanity.
deleted 6y ago
[deleted]
jblow 6y ago
This is right. The OP said he is "disillusioned with technology" but I didn't see actual technology being described as the problem with any point. So there's a conflation here happening between technology and "tech" companies. And I can only say the phrase "tech" companies while using sarcasm quotes around "tech", because almost nobody at any of these companies develops actual technology. And that's a big part of the problem.
- kristopolous 6y ago
  There's a subculture that's reinvented the merits of software engineering to being as ornate and ceremonious as possible. It doesn't have to work well, or be bug free, or compatible with the previous version, or address any real world need. No! Instead it has to use fashionable technology and be extremely complicated so other programmers can see how incredibly clever they are! Almost like they took a random bug from the issue tracker by looking at last nights lotto numbers and then they opened to a random page of Knuth by letting a fan blow on the pages for 5 minutes and said "alright, I'll solve this problem in that way! Surely everyone will acknowledge my genius!" It may be a slow lumbering buggy pile of brittle barely functional code about to implode, but boy does it look nice!
  - kovac 6y ago
    I don't agree with this view. I agree with the original commentor's comment. I do this myself outside of work just to enjoy building something without the responsibility of having to maintain it with 20 other engineers for two more decades. However, even I can see that a team would get burnt if they built an enterprise software the way I code my personal email client. The problem here is that people forget that building software professionally is an engineering job. Like other forms of engineering, there are processes and good practices to facilitate both functional and non functional aspects of a software and the building process. While the extra burden of version control, testability and extendability takes some of the fun away, I would have reservations working with someone who pushes directly to a release branch, does not write test and hardcode values instead of uaing configuration. It's about balance and realising that job is a job.
thorwasdfasdf 6y ago
This. and let's add: don't use fancy frameworks (that are cool and popular) that cause many headaches for you down the road.
Der_Einzige 6y ago
This is the best and worst part about open source dev. Pro: You can do whatever you want Con: You can do whatever you want (including things that will bite you in the ass later) I've also noticed that AI/ML falls into the exact same pit because many folks there are cowboy coding
rwesty 6y ago
This is really, really bad advice. Mutiny is hardly an answer to the problem here. It will certainly temporarily avoid the problems you face but if you are a member of a team and this is truly how you act you will get chucked out very quickly. But since you bring up a few of the issues you are facing it's important to address them. I want to focus on unit tests to start. When I started my first programming job a couple of years ago I joined a team that demanded 100% code coverage. I hated them so much. I was still learning the ropes at this company and I only saw the unit tests as a barrier to getting my work done and earning my paycheck. My first solution was to create bogus tests that always passed. That was quickly discovered and I was reprimanded. My second solution was to get colleagues who shared my hate for unit tests to approve my PRs before they were reviewed by my team. That too was thwarted. Then one day I was working with a teammate on a new feature and we discovered a bug. He quickly opened up a test file and wrote a unit test, then he went tried a couple solutions until the test turned green. Then he looked at me and said, "When when you are working in a pile of crap, testing makes you feel more confident about your code." That was my first insight into the value of testing. Eventually I came around and stopped trying to avoid tests. I just did the damn work. Once I established trust with my teammates they began to let the pressure off my PRs and slowly the displeasure of writing tests went away. You pointed out a few different coding practices that frustrate you. And to be honest, those coding practices are not the gospel and should be deployed only when truly needed. However I think you have a serious problem with what a lot of us call being a good teammate. At the end of the day your goal should be to get the product shipped, once you focus on getting your features out the door, unit testing and pull requests become minor details in that process. At the end of the day those are just a cutesy to your teammates to show them that you are willing to be a responsible and helpful team member. Stop trying to fight everyone so much and maybe you will enjoy your job a little more.
- tygrak 6y ago
  The person you are replying to isn't suggesting to not do these things while working as a programmer professionally.
- catalogia 6y ago
  I don't think the GP's advice is meant for team projects. > "Don't make enterprise software. [...] Don't accept pull requests. Simply write software for yourself and have fun doing it."
unclebucknasty 6y ago
This is a great point, laced with justified indignation. As a graybeard, I've seen multiple generations of "how to do software" and the most recent are the least fun. A lot of this is driven by the agile approach. It's tailor-made for dev burnout: from the endless tight cycles that force people into an infinite loop of productivity with scant satisfaction that comes with "completion", to all of the tools and philosophies designed to juice that endless loop to be successful/workable. CI/CD, Git, TDD, etc. These all impose on the developer's creativity, independence, and enjoyment. They turn devs into cogs--assembly line workers who must not stop the line at any cost. One example: back in the day there was a nightly build, not a continuous one. And, you checked out a file, worked on it, and checked it back in. If someone else needed it they had to wait. That obviously had its limitations and it seems laughable by today's standards. But, it was reflective of a human pace that considered devs as people vs. optimizable assets. That is, it was workable because the expectations on devs weren't insane. But, now we commit and merge. Think of how much less fun it is to spend your time resolving merge conflicts. More to the point, the approach itself implies a chaotic pace wherein code that meets the standards of a certain box must be produced at all times. Devs must bear the cost of resolving any conflicts (literally) that arise from this chaotic pace. Likewise, with CI/CD. And don't get me started on the monkey-work that is TDD. You might argue that it improves code quality. But, it's hard to make the case that it improves job satisfaction. If you move more work from the creative, problem-solving bucket into the busy-work bucket, the result will not be personal fulfillment. Does agile increase productivity for companies? Sure. But, it comes at a high cost that's mostly paid by devs.
- pnw_hazor 6y ago
  The commodification/fungibilty of programmers is the goal. See, also open office plans. I think the bad started for me (long ago) when the Microsoft style management and so-called MS best practices began to conquer the PNW. In the late 90's a company I was in started driving to an exit. First they hired an ex-MS Group Program Mgr, whatever that means. Next, came tons of PMs pulling one or two devs into their projects/features. Doing it the MS way I guess (at least the MS way back then). I was a manager, I refused to dole out my team members to PMs -- everything my team did was run through me. I don't even think I let them enter individual devs into their project plans. Just the team. This worked well for us (my team) because I knew their capabilities, interests, family commitments, likes/dislikes, etc. I could adjust resources as needed to meet the team commitments. We had successes and failures as a team. PMs who tried put pressure on my devs behind my back would really catch it from me. My management style wasn't any new idea, it was what we did in the Army. Assign a team a task, then the team leader ensures the task is completed by the team. It was a good time, we were the only real team in the place as the other managers embraced the MS way of doing things. At end (right before dotcom bust) the company started doing some Agile-lite with two-week release cycles absent stories, standups, etc. I did like that enough to put it place at the next company I worked at. I did get burned out though, mostly because I didn't want deal with what the industry had become as the last startup I was at petered out. I still love programming but not enough to do it in modern shop.
bori5 6y ago
Thats how some places operate by default.
harimau777 6y ago
I think that it would be difficult to keep a job following that approach.
thewarrior 6y ago
I like it. Jean Paul Sartre but for coders.
woah 6y ago
No unit tests?? You should just recommend never running your code if that's where you're going.
- tonyarkles 6y ago
  The thing that unit tests are really good for is providing a safety net when you make changes. And I love them. I have a few multi-year projects that sit and do their thing for months at a time with no changes; when I come back to them with a client request, the test suite is awesome for making sure that whatever I just changed didn't break something else (alternatively, the tests point out an assumption I made when writing the tests and the test needs to be changed). Either way, I appreciate it. Especially when there've been changes done by other people that I wasn't aware of. Buuuuut... a lot of the personal projects I've worked on have zero unit tests. Maybe they have a couple of tests around a complicated algorithm, but mostly... no automated testing. What they do have though is a) version control, and b) a fast-iteration platform underneath them. They're also generally well factorered into small chunks. As an example, I have a package that takes an org-mode file and extracts time entries to drive into time tracking software a client uses. Written in Lisp, zero tests. Every month I fire it up, look at the table of entries it's about to post, and hit "go". Looking at the table of entries provides two sanity checks: first, that I properly logged my hours that month (I'll occasionally forget to clock out for a weekend and rack up a 48 hour time log), and second, that it didn't encounter a bug while doing the processing. As of around September of last year, this program is done, and does its job perfectly every month. Another example, also in Lisp, is used for making estimates for my clients. I give it a list of tasks with 3-point estimates, it churns through and calculates all the means and standard deviations, generates a file for Pandoc to consume, and spits out a PDF. I use it every couple of months. No tests, all done inside the SBCL repl. I obviously proofread the output PDF before sending it to a client, but that's again to check for bugs and to check for brain farts. I've worked on great codebases that have giant test suites, and I've worked on terrible codebases that have giant test suites. And likewise for no test suites. While I appreciate the sentiment, I think it's dangerous to talk in absolutes like that. While I agree there is probably some degree of correlation between whether or not a codebase has a unit test suite and whether it's good code, writing unit tests does not intrinsically make the codebase good, and not writing unit tests does not intrinsically make a codebase bad.
dnprock 6y ago
This comment resonates with me. I've been to meetings where we spent hours and discussed these things. I tend to ignore them and do as instructed. The work is pretty boring. But I get paid for it. I think my peers don't like me. I don't blend in. I'm not part of the culture. I will eventually get dismissed. But I'm not mad or angry. I move on to the next project where I contribute more effectively. We need to accept change. Your company eventually will move you to a new project or dismiss you. They need to put your software baby on maintenance and squeeze out the last bucks before they shut it down. Life continues with or without you. If you become pro-active, you'll have a fun ride with it.
highlysyntropic 6y ago
This is awesome. You, sir, took the red pill. BTW, do you work for Tesla? The batteries in your name.
- battery_cowboy 6y ago
  I worked with Tesla grid batteries (powerpack installations) at my last job, but I'm currently looking for work. I just got tired of "engineering" my personal projects, i just "program" them now!
  - senderista 6y ago
    That's a great approach. I personally enjoy coding novel or obscure data structures which I'd never get to implement at work, but hopefully might be useful to someone.
bshoemaker 6y ago
Jesus you sound like a nightmare to work with
wmij 6y ago
> Don't write unit tests. Don't accept pull requests. Simply write software for yourself and have fun doing it. There's a careful balance here though right? For most projects your first users or clients are the unit tests. Why not have a future of repeatable client/user tests that insulate from regressions and to be your wingman to navigate future iterations? Also for me, I still review and accept my own pull requests on solo projects, because it is that last step when working on my own where I know I'm at a good point looking at my diffs and the last step in introducing mistakes.
- AndrewThrowaway 6y ago
  You are sooo missing the point... Lets change the story to be about an artist being burnt out of art industry. Suddenly he has to deal with all the grant money, politics of the gallery etc. Feels like he doesn't want to do anything with art anymore. And somebody in the thread suggests the artist just go to the nature and paint and don't think about any art styles and acceptance of peers and trends and etc. Just give yourself to painting and don't think about anything. Just paint with a coal on stones and loose yourself in it. And you comment would be something like "There's a balance here though, you still need to paint on canvas with acrylic or something, otherwise you won't be able to validate your art in the future for you to progress etc."
mesaframe 6y ago
But, what if you want to improve? What if you actually want to write better code? Robust code is something you earn.
- isakkeyten 6y ago
  But what is good code? What is bad code? I know what is slow code and what is fast, but not always fast is good and slow bad. So basically, good/bad code is mainly around maintainability. And if you are the only person that maintains it and can maintain it then you only need the code to be 'as good' as your ability to retain the memory of it's structure.
  - mesaframe 6y ago
    I don't know how your comment is contributing to the conversation. No one asked about the definition of good code. The definition was assumed to be understood.
    - mellow2020 6y ago
      Asking "but what if?" without actually making the point you think is implied in that rhetorical question isn't much of a conversation to begin with.
      - mesaframe 6y ago
        That does not justify an irrelevant answer. If something it not understood then questions should be asked.
dguest 6y ago
In my field you're describing "playing the game", ironically. In academia the aim is to get a proof of principal, write a short paper, and move on. If you care about reusable code you are building a foundation for someone else's success, but not necessarily your own. Neither side is wrong, it's just a different game.
deleted 6y ago
[deleted]
nicbou 6y ago
> Don't make enterprise software. Don't write unit tests. Don't accept pull requests. Simply write software for yourself and have fun doing it. Forget refactoring code into modules, just fucking code I've found a really nice perspective on this recently: An app can be a home-cooked meal [1] It's okay to build things that aren't popular, that don't scale, or that aren't economically viable, for the delight of a few users. 1: https://www.robinsloan.com/notes/home-cooked-app/ https://www.robinsloan.com/notes/home-cooked-app/
- pbhjpbhj 6y ago
  OT: someone close to me never tastes the food they cook, I can't understand that. You don't know how long to cook it, or how to season it, or if the balance of sour/sweet/salt/umami/whatever is right at the point you can fix it ... But that's more an analogue of "use your program before you release it".
  - Insanity 6y ago
    I guess they do eat it though, and then improve the recipe for next time by adjusting what they like. More like an AI approach in that case :D At least they are 'dogfooding' it and not just letting others eat it I hope :)
  - CrazyStat 6y ago
    When I'm cooking food that I'm going to eat myself I try to limit tasting. If I taste a lot I'm likely to end up with sensory satiation and won't enjoy the meal much by the time I sit down at the table. Just smelling the food while I'm cooking it can trigger this for some dishes (typically curries and other similarly pungent dishes). If I'm cooking a dish that I've cooked at least three or so times before I generally have a good idea of how things should be going and I can get away with only tasting once or twice at the end.
- mark_l_watson 6y ago
  I am in this place. I have been working for months on an app that perhaps a few dozen people might want (in the semantic web space). If I have a few enthusiastic users who provide some feedback, I am good with that.
Hendrikto 6y ago
> just do whatever you want in the moment, bit by bit I thought we were talking about technology. You gave a recipe for spaghetti.
- throwanem 6y ago
  Sometimes making up a nice plate of spaghetti is just the thing to help get you through a rough time. Engineering has its place. But you can also make art with an engine lathe, and doing just that every now and again can be a balm to the soul.
not_a_moth 6y ago
Rails was engineered around developer happiness, and I kind of miss those days. And while React is cool I'm still kind of resentful that companies insist on using React and adding a whole Node env when basic jQuery would have done the job. Web development could be stupidly simple if we wanted it to be. I feel like it got too easy, and suddenly there were waves of bootcamp grads, and a lot of developers resented that.
- wlll 6y ago
  Well, I refuse to use Javascript because I hate it, and it's ecosystem, and I've managed to do just fine job-wise. I think not doing JS is still an option.
- gjs278 6y ago
  I still don’t understand what react is. can I use react + golang and no nodejs? it seems like every guide assumes I want to use nodejs and I don’t. can I use react and php?
wlll 6y ago
> Don't write unit tests. I have written personal projects both with and without tests and every single time I don't write them I wish I had, usually pretty quickly. The time you save by not writing those first few tests always seems to be lost, and then some, pretty quickly in the extra manual testing that is required.
ehnto 6y ago
There has been a lot of cargo-culted best practice in the last 5-10 years that is unjustified busy-work. I have a little secret in the same vain. I turn off all email notifications, and have no apps on my phone. Never been an issue. I just check the source when it makes sense during my work day. No more senseless interruptions, no worrying about things that aren't actually on my agenda. A smooth workflow and peace of mind.
golergka 6y ago
But what if all the stuff that you've described is the most fun part of writing software?...

gfosco 6y ago

That's generally an unpopular and unwelcome opinion here, but I agree with you 100%. edit: and i'll happily take those downvotes, they are delicious thank you.

cyborgx7 6y ago
you are not getting downvotes because people are disagreeing with you
- xparco 6y ago
  Stop lying
0xdeadbeefbabe 6y ago
Not on this story. Those other folks are too busy configuring stuff, arguing about curl website/script.sh | sh, and building microservices to feel burnt out yet.

aprdm 6y ago

This! (And wait until you figure out there’s a lot of real companies running like that..) I would say to also work in a domain you care about and like. I don’t like technology for technology sake and never did. I like solving problems and see technology as a tool to do so. I love the company I work for, the people and the problems we get to solve. I love even more when I solve them without the need to write a single line of code.

Royalaid 6y ago

I think this is a natural reaction to advice being over prescribed and totally agree that in your free time you should do whatever it is you want and this is solid advice. BUT I think we should also acknowledge that everything that slows you down in your free time has a reason for existing and most of that is communication or knowledge sharing within a team. Naming conventions, unit tests, and general documentation all exist to help other team members keep up with the pace of changes in the repository. If you're not planning to do something in a team setting or for this to be consumed outside of the work that you do then you don't need these things. But if you want to share with everyone else it's important that you don't totally ignore these things because it will come back to bite you in the long run.

wolco 6y ago
The idea is to stop trying to make it easier to share and others to use and just write something that works for you. Kinda like the idea for personal. Why spend so much effort to structure projects so others can use when chances are they won't or you don't care if they do. Work is governed by different realities.
deleted 6y ago
[deleted]

makapuf 6y ago

Thats exactly what i did while working on dreaded big data. Got myself a microcontroller, implemented a small arm console and write fucking low level C code optimized the heck of cpu cycles for tiny games, no code reuse, no interfaced, no deadlines, no refacto, no security, no network, no politics. Barely version control (with appropriate "update" commit messages). Kept me sane while doing those things at work.

ay 6y ago
+1 on the small 1-2 weekend tangible projects, that you may have wanted to build before, but never got to, they are great for morale. This weekend I implemented RS232-powered RGB LED that is controlled attiny85, which reacts to strings sent to that very same RS232. A gross violation of standard, probably, but it works! It definitely added a lot of joy. I typed “git init” only after I finished the first working version which had a regular One-color LED, and could not yet do blinking :-)
- BenjiWiebe 6y ago
  For even more fun with low level breaking of standards, bit-banging rs232 is fun and very doable. Don't use timers for timing either, just spin the cpu the right number of times. :)
  - ay 6y ago
    This project actually does decode of Rs232 data, with the special prefix triggering the interpreter mode where you can control the color and delay between the cycles. Only ground and TX pins are used to connect. Oh, and no interrupts - poll for the start bit while running the currently programmed light animation cycle :-) One thing that made the development of it all immensely easier was having a Saleae logic analyzer. Highly recommend it (no affiliation, just a happy customer).
cblum 6y ago
Interesting, I’m on the same boat. Embedded systems and low-level coding are my beacons of sanity.

deleted 6y ago

[deleted]

jblow 6y ago

This is right. The OP said he is "disillusioned with technology" but I didn't see actual technology being described as the problem with any point. So there's a conflation here happening between technology and "tech" companies. And I can only say the phrase "tech" companies while using sarcasm quotes around "tech", because almost nobody at any of these companies develops actual technology. And that's a big part of the problem.

kristopolous 6y ago
There's a subculture that's reinvented the merits of software engineering to being as ornate and ceremonious as possible. It doesn't have to work well, or be bug free, or compatible with the previous version, or address any real world need. No! Instead it has to use fashionable technology and be extremely complicated so other programmers can see how incredibly clever they are! Almost like they took a random bug from the issue tracker by looking at last nights lotto numbers and then they opened to a random page of Knuth by letting a fan blow on the pages for 5 minutes and said "alright, I'll solve this problem in that way! Surely everyone will acknowledge my genius!" It may be a slow lumbering buggy pile of brittle barely functional code about to implode, but boy does it look nice!
- kovac 6y ago
  I don't agree with this view. I agree with the original commentor's comment. I do this myself outside of work just to enjoy building something without the responsibility of having to maintain it with 20 other engineers for two more decades. However, even I can see that a team would get burnt if they built an enterprise software the way I code my personal email client. The problem here is that people forget that building software professionally is an engineering job. Like other forms of engineering, there are processes and good practices to facilitate both functional and non functional aspects of a software and the building process. While the extra burden of version control, testability and extendability takes some of the fun away, I would have reservations working with someone who pushes directly to a release branch, does not write test and hardcode values instead of uaing configuration. It's about balance and realising that job is a job.

thorwasdfasdf 6y ago

This. and let's add: don't use fancy frameworks (that are cool and popular) that cause many headaches for you down the road.

Der_Einzige 6y ago

This is the best and worst part about open source dev. Pro: You can do whatever you want Con: You can do whatever you want (including things that will bite you in the ass later) I've also noticed that AI/ML falls into the exact same pit because many folks there are cowboy coding

rwesty 6y ago

This is really, really bad advice. Mutiny is hardly an answer to the problem here. It will certainly temporarily avoid the problems you face but if you are a member of a team and this is truly how you act you will get chucked out very quickly. But since you bring up a few of the issues you are facing it's important to address them. I want to focus on unit tests to start. When I started my first programming job a couple of years ago I joined a team that demanded 100% code coverage. I hated them so much. I was still learning the ropes at this company and I only saw the unit tests as a barrier to getting my work done and earning my paycheck. My first solution was to create bogus tests that always passed. That was quickly discovered and I was reprimanded. My second solution was to get colleagues who shared my hate for unit tests to approve my PRs before they were reviewed by my team. That too was thwarted. Then one day I was working with a teammate on a new feature and we discovered a bug. He quickly opened up a test file and wrote a unit test, then he went tried a couple solutions until the test turned green. Then he looked at me and said, "When when you are working in a pile of crap, testing makes you feel more confident about your code." That was my first insight into the value of testing. Eventually I came around and stopped trying to avoid tests. I just did the damn work. Once I established trust with my teammates they began to let the pressure off my PRs and slowly the displeasure of writing tests went away. You pointed out a few different coding practices that frustrate you. And to be honest, those coding practices are not the gospel and should be deployed only when truly needed. However I think you have a serious problem with what a lot of us call being a good teammate. At the end of the day your goal should be to get the product shipped, once you focus on getting your features out the door, unit testing and pull requests become minor details in that process. At the end of the day those are just a cutesy to your teammates to show them that you are willing to be a responsible and helpful team member. Stop trying to fight everyone so much and maybe you will enjoy your job a little more.

tygrak 6y ago
The person you are replying to isn't suggesting to not do these things while working as a programmer professionally.
catalogia 6y ago
I don't think the GP's advice is meant for team projects. > "Don't make enterprise software. [...] Don't accept pull requests. Simply write software for yourself and have fun doing it."

unclebucknasty 6y ago

This is a great point, laced with justified indignation. As a graybeard, I've seen multiple generations of "how to do software" and the most recent are the least fun. A lot of this is driven by the agile approach. It's tailor-made for dev burnout: from the endless tight cycles that force people into an infinite loop of productivity with scant satisfaction that comes with "completion", to all of the tools and philosophies designed to juice that endless loop to be successful/workable. CI/CD, Git, TDD, etc. These all impose on the developer's creativity, independence, and enjoyment. They turn devs into cogs--assembly line workers who must not stop the line at any cost. One example: back in the day there was a nightly build, not a continuous one. And, you checked out a file, worked on it, and checked it back in. If someone else needed it they had to wait. That obviously had its limitations and it seems laughable by today's standards. But, it was reflective of a human pace that considered devs as people vs. optimizable assets. That is, it was workable because the expectations on devs weren't insane. But, now we commit and merge. Think of how much less fun it is to spend your time resolving merge conflicts. More to the point, the approach itself implies a chaotic pace wherein code that meets the standards of a certain box must be produced at all times. Devs must bear the cost of resolving any conflicts (literally) that arise from this chaotic pace. Likewise, with CI/CD. And don't get me started on the monkey-work that is TDD. You might argue that it improves code quality. But, it's hard to make the case that it improves job satisfaction. If you move more work from the creative, problem-solving bucket into the busy-work bucket, the result will not be personal fulfillment. Does agile increase productivity for companies? Sure. But, it comes at a high cost that's mostly paid by devs.

pnw_hazor 6y ago
The commodification/fungibilty of programmers is the goal. See, also open office plans. I think the bad started for me (long ago) when the Microsoft style management and so-called MS best practices began to conquer the PNW. In the late 90's a company I was in started driving to an exit. First they hired an ex-MS Group Program Mgr, whatever that means. Next, came tons of PMs pulling one or two devs into their projects/features. Doing it the MS way I guess (at least the MS way back then). I was a manager, I refused to dole out my team members to PMs -- everything my team did was run through me. I don't even think I let them enter individual devs into their project plans. Just the team. This worked well for us (my team) because I knew their capabilities, interests, family commitments, likes/dislikes, etc. I could adjust resources as needed to meet the team commitments. We had successes and failures as a team. PMs who tried put pressure on my devs behind my back would really catch it from me. My management style wasn't any new idea, it was what we did in the Army. Assign a team a task, then the team leader ensures the task is completed by the team. It was a good time, we were the only real team in the place as the other managers embraced the MS way of doing things. At end (right before dotcom bust) the company started doing some Agile-lite with two-week release cycles absent stories, standups, etc. I did like that enough to put it place at the next company I worked at. I did get burned out though, mostly because I didn't want deal with what the industry had become as the last startup I was at petered out. I still love programming but not enough to do it in modern shop.

bori5 6y ago

Thats how some places operate by default.

harimau777 6y ago

I think that it would be difficult to keep a job following that approach.

thewarrior 6y ago

I like it. Jean Paul Sartre but for coders.

woah 6y ago

No unit tests?? You should just recommend never running your code if that's where you're going.

tonyarkles 6y ago
The thing that unit tests are really good for is providing a safety net when you make changes. And I love them. I have a few multi-year projects that sit and do their thing for months at a time with no changes; when I come back to them with a client request, the test suite is awesome for making sure that whatever I just changed didn't break something else (alternatively, the tests point out an assumption I made when writing the tests and the test needs to be changed). Either way, I appreciate it. Especially when there've been changes done by other people that I wasn't aware of. Buuuuut... a lot of the personal projects I've worked on have zero unit tests. Maybe they have a couple of tests around a complicated algorithm, but mostly... no automated testing. What they do have though is a) version control, and b) a fast-iteration platform underneath them. They're also generally well factorered into small chunks. As an example, I have a package that takes an org-mode file and extracts time entries to drive into time tracking software a client uses. Written in Lisp, zero tests. Every month I fire it up, look at the table of entries it's about to post, and hit "go". Looking at the table of entries provides two sanity checks: first, that I properly logged my hours that month (I'll occasionally forget to clock out for a weekend and rack up a 48 hour time log), and second, that it didn't encounter a bug while doing the processing. As of around September of last year, this program is done, and does its job perfectly every month. Another example, also in Lisp, is used for making estimates for my clients. I give it a list of tasks with 3-point estimates, it churns through and calculates all the means and standard deviations, generates a file for Pandoc to consume, and spits out a PDF. I use it every couple of months. No tests, all done inside the SBCL repl. I obviously proofread the output PDF before sending it to a client, but that's again to check for bugs and to check for brain farts. I've worked on great codebases that have giant test suites, and I've worked on terrible codebases that have giant test suites. And likewise for no test suites. While I appreciate the sentiment, I think it's dangerous to talk in absolutes like that. While I agree there is probably some degree of correlation between whether or not a codebase has a unit test suite and whether it's good code, writing unit tests does not intrinsically make the codebase good, and not writing unit tests does not intrinsically make a codebase bad.

dnprock 6y ago

This comment resonates with me. I've been to meetings where we spent hours and discussed these things. I tend to ignore them and do as instructed. The work is pretty boring. But I get paid for it. I think my peers don't like me. I don't blend in. I'm not part of the culture. I will eventually get dismissed. But I'm not mad or angry. I move on to the next project where I contribute more effectively. We need to accept change. Your company eventually will move you to a new project or dismiss you. They need to put your software baby on maintenance and squeeze out the last bucks before they shut it down. Life continues with or without you. If you become pro-active, you'll have a fun ride with it.

highlysyntropic 6y ago

This is awesome. You, sir, took the red pill. BTW, do you work for Tesla? The batteries in your name.

battery_cowboy 6y ago
I worked with Tesla grid batteries (powerpack installations) at my last job, but I'm currently looking for work. I just got tired of "engineering" my personal projects, i just "program" them now!
- senderista 6y ago
  That's a great approach. I personally enjoy coding novel or obscure data structures which I'd never get to implement at work, but hopefully might be useful to someone.

bshoemaker 6y ago

Jesus you sound like a nightmare to work with

wmij 6y ago

> Don't write unit tests. Don't accept pull requests. Simply write software for yourself and have fun doing it. There's a careful balance here though right? For most projects your first users or clients are the unit tests. Why not have a future of repeatable client/user tests that insulate from regressions and to be your wingman to navigate future iterations? Also for me, I still review and accept my own pull requests on solo projects, because it is that last step when working on my own where I know I'm at a good point looking at my diffs and the last step in introducing mistakes.

AndrewThrowaway 6y ago
You are sooo missing the point... Lets change the story to be about an artist being burnt out of art industry. Suddenly he has to deal with all the grant money, politics of the gallery etc. Feels like he doesn't want to do anything with art anymore. And somebody in the thread suggests the artist just go to the nature and paint and don't think about any art styles and acceptance of peers and trends and etc. Just give yourself to painting and don't think about anything. Just paint with a coal on stones and loose yourself in it. And you comment would be something like "There's a balance here though, you still need to paint on canvas with acrylic or something, otherwise you won't be able to validate your art in the future for you to progress etc."

mesaframe 6y ago

But, what if you want to improve? What if you actually want to write better code? Robust code is something you earn.

isakkeyten 6y ago
But what is good code? What is bad code? I know what is slow code and what is fast, but not always fast is good and slow bad. So basically, good/bad code is mainly around maintainability. And if you are the only person that maintains it and can maintain it then you only need the code to be 'as good' as your ability to retain the memory of it's structure.
- mesaframe 6y ago
  I don't know how your comment is contributing to the conversation. No one asked about the definition of good code. The definition was assumed to be understood.
  - mellow2020 6y ago
    Asking "but what if?" without actually making the point you think is implied in that rhetorical question isn't much of a conversation to begin with.
    - mesaframe 6y ago
      That does not justify an irrelevant answer. If something it not understood then questions should be asked.

dguest 6y ago

In my field you're describing "playing the game", ironically. In academia the aim is to get a proof of principal, write a short paper, and move on. If you care about reusable code you are building a foundation for someone else's success, but not necessarily your own. Neither side is wrong, it's just a different game.

deleted 6y ago

[deleted]

nicbou 6y ago

> Don't make enterprise software. Don't write unit tests. Don't accept pull requests. Simply write software for yourself and have fun doing it. Forget refactoring code into modules, just fucking code I've found a really nice perspective on this recently: An app can be a home-cooked meal [1] It's okay to build things that aren't popular, that don't scale, or that aren't economically viable, for the delight of a few users. 1: https://www.robinsloan.com/notes/home-cooked-app/ https://www.robinsloan.com/notes/home-cooked-app/

pbhjpbhj 6y ago
OT: someone close to me never tastes the food they cook, I can't understand that. You don't know how long to cook it, or how to season it, or if the balance of sour/sweet/salt/umami/whatever is right at the point you can fix it ... But that's more an analogue of "use your program before you release it".
- Insanity 6y ago
  I guess they do eat it though, and then improve the recipe for next time by adjusting what they like. More like an AI approach in that case :D At least they are 'dogfooding' it and not just letting others eat it I hope :)
- CrazyStat 6y ago
  When I'm cooking food that I'm going to eat myself I try to limit tasting. If I taste a lot I'm likely to end up with sensory satiation and won't enjoy the meal much by the time I sit down at the table. Just smelling the food while I'm cooking it can trigger this for some dishes (typically curries and other similarly pungent dishes). If I'm cooking a dish that I've cooked at least three or so times before I generally have a good idea of how things should be going and I can get away with only tasting once or twice at the end.
mark_l_watson 6y ago
I am in this place. I have been working for months on an app that perhaps a few dozen people might want (in the semantic web space). If I have a few enthusiastic users who provide some feedback, I am good with that.

Hendrikto 6y ago

> just do whatever you want in the moment, bit by bit I thought we were talking about technology. You gave a recipe for spaghetti.

throwanem 6y ago
Sometimes making up a nice plate of spaghetti is just the thing to help get you through a rough time. Engineering has its place. But you can also make art with an engine lathe, and doing just that every now and again can be a balm to the soul.

not_a_moth 6y ago

Rails was engineered around developer happiness, and I kind of miss those days. And while React is cool I'm still kind of resentful that companies insist on using React and adding a whole Node env when basic jQuery would have done the job. Web development could be stupidly simple if we wanted it to be. I feel like it got too easy, and suddenly there were waves of bootcamp grads, and a lot of developers resented that.

wlll 6y ago
Well, I refuse to use Javascript because I hate it, and it's ecosystem, and I've managed to do just fine job-wise. I think not doing JS is still an option.
gjs278 6y ago
I still don’t understand what react is. can I use react + golang and no nodejs? it seems like every guide assumes I want to use nodejs and I don’t. can I use react and php?

wlll 6y ago

> Don't write unit tests. I have written personal projects both with and without tests and every single time I don't write them I wish I had, usually pretty quickly. The time you save by not writing those first few tests always seems to be lost, and then some, pretty quickly in the extra manual testing that is required.

ehnto 6y ago

There has been a lot of cargo-culted best practice in the last 5-10 years that is unjustified busy-work. I have a little secret in the same vain. I turn off all email notifications, and have no apps on my phone. Never been an issue. I just check the source when it makes sense during my work day. No more senseless interruptions, no worrying about things that aren't actually on my agenda. A smooth workflow and peace of mind.

golergka 6y ago

But what if all the stuff that you've described is the most fun part of writing software?...