7 ms·

I am really hating working in the current state of the industry right now. I am used to writing robust, clear, well-tested, and easy to maintain systems. The j

• Jade_Jet 6y ago
  You’ve spelled out exactly how I feel.
• xwdv 6y ago
  Just means you gotta work higher up in the food chain. You need a new job. Build what other developers eat.
  • caretak3r 6y ago
    Build what other developers eat. I am interested in this topic, can you elaborate? Or any thoughts from anyone?
    • thethethethe 6y ago
      I think OP is referring to things like working on cloud infrastructure, systems software like web servers and reverse proxies, programming languages, or foundational libraries and frameworks libraries—all of which are consumed by application developers
      • Ericson2314 6y ago
        Or have my job, switching periodically between on all that stuff and the end application. Make sure the tools you make are actually useful for the problem they purport to solve! We just refuse to use vendor-lock-in cloud crap as a matter of principle. Regular server processes (though Haskell), regular machines (the NixOS), PostgreSQL, no problem.
        • Frost1x 6y ago
          Must be nice, I'm surrounded by zombies that are either RDD or truly naive. Most of the ecosystem this org works with really doesn't make sense for "cloud." Most of it should be internal infrastructure for an entire host of reasons aside from occasionally using EC2 instances for special case bursts of computing demands. Instead theres an obsession with AWS with no solid rationale.
          • xwdv 6y ago
            How about AWS Lightsail instead of EC2?
          • Ericson2314 6y ago
            Sorry to hear that! It's a real shame when people contort themselves to give Bezos more money.
  • GolDDranks 6y ago
    If you build what other developers eat, doesn't that mean working _lower_ in the food chain?
    • quaintdev 6y ago
      I think both are correct.
    • dbtc 6y ago
      The plankton shall inherit the ocean.
    • bloak 6y ago
      Real food chains are cyclic, a bit like in https://en.wikipedia.org/wiki/On_Ilkla_Moor_Baht_%27at https://en.wikipedia.org/wiki/On_Ilkla_Moor_Baht_%27at Bad metaphorical usage of the term "food chain" is an example of "office speak". Personally, I don't much like it.
  • dylan604 6y ago
    Great, another fad library to use. That's definitely what we need.
• agumonkey 6y ago
  it's funny because this looks like badly organized workplace in a group of skilled people it can still happen is it due to bad leadership ?
  • deleted 6y ago
    [deleted]
  • Mandatum 6y ago
    Governance and lack of a dictator with sane "technical debt to income" ratio. Unless you're NASA, you're not going to get there with a smart committee. You need a single person that can make the right technical decision 80% of the time and business decision 120% of the time.
    • cookiecaper 6y ago
      Definitely the case, people don't realize how much a weak link in the chain can break the whole structure, and just how much influence the command structure can have. I've worked places where all my peers were very smart and well-qualified and still ended up outputting what boils down to smart trash because a middle manager somewhere refused to allow them to structure things well. Conway's Law isn't dependent on the group's collective IQ. A little sensitive on this due to a recent experience where I was hired and given "ownership" only to have my very modest proposals for changes shot down if not just entirely ignored. Some "ownership"!
  • jmnicolas 6y ago
    > it's funny because this looks like badly organized workplace You probably should get out of the HN bubble more often, a badly organized workplace is the norm not the exception. (I hope it doesn't come as condescending since it's not my intention)
    • agumonkey 6y ago
      It seriously came as condescending since I'm quite removed from HN bubble. At least you warned me, thanks. My comment is not about the norm but about the nature of the work structure. See I've mostly been working in average (non IT) places. I can understand average salesman and clerks having troubles organizing, dealing with computer issues, bad software, and cracking under managers because they don't have Masters degrees in abstract algebra applied to relational databases. So I assumed that in an IT company the skills would influence the structure. I guess it boils down to low level politics as usual.
• arvinsim 6y ago
  You try to explain the importance of testing and good code quality to your higher ups only to be retorted with "but we need this to be out in X weeks!". And then when a production bug is revealed, they then angrily ask "why are these errors occurring?"
  • RikNieu 6y ago
    I have PTSD just reading this.
  • monksy 6y ago
    Or when you tell them to get to that in X weeks that you can't guarentee it against breaking bugs. Later "WE CAN"T PUT THIS IN FRONT OF A CUSTOMER"
  • adriancr 6y ago
    I've seen the reverse happen at some companies. Managers getting taken advantage of by allowing people to do anything in the name of 'technical debt' 'code quality', resulting in more bugs, lots of needless refactoring, tons of layers of abstraction and tests that actually do close to nothing. Result is they are then surprised it takes a long time to develop new features where competitors do it faster and eat their lunch. There needs to be some sort of balance, companies need to make money to allow for proper code to be developed, second is also valuable as long as it makes sense financially as well.
    • watwut 6y ago
      > allowing people to do anything in the name of 'technical debt' 'code quality', resulting in more bugs, lots of needless refactoring, tons of layers of abstraction and tests that actually do close to nothing. This heavily points to dysfunctional development team with fault being primary on tech leads making more and more mess the more they code. > companies need to make money to allow for proper code to be developed, second is also valuable as long as it makes sense financially as well. This one is merely about putting less resources on development. I don't think it fixes the dysfunctional team above, it is just avoid the issues. There is nothing that would make developers write useful tests. Nothing that would change tech leads, nothing that would prevent unmaintainable code appearing again. Had the constantly refactoring team ended with very good code for too much of price, then cutting resources is likely to lead to better trade off. But that is not their case, their case is that they don't know how to write good code.
• anonytrary 6y ago
  > The job right now seems just stitching AWS services together, and spending the rest of your time debugging and putting out fires. This is exactly what our engineers do, too! I am kept motivated by what we are able to do with what we've stitched together. But yes, knowing it is a bunch of plastic garbage underneath is... depressing, almost.
• nix23 6y ago
  >I am used to writing robust, clear, well-tested, and easy to maintain systems Maybe then go into the HPC/Defence/Air/Space/Masstransport-Industry, they will love you, no BS thats exacly what they want and need.
• zorked 6y ago
  > robust, clear, well-tested, and easy to maintain systems I wonder if that's how the implementors of software that actually lasted for decades would describe their work or motivation. Does this describe Unix, for example? In particular the old AT&T version, not GNU (or even modern BSD) code.
  • kwhat4 6y ago
    May of the design philosophies laid by smart people like Eric Raymond are very well documented: https://medium.com/programming-philosophy/eric-raymond-s-17-unix-rules-399ac802807 https://medium.com/programming-philosophy/eric-raymond-s-17-... https://en.wikipedia.org/wiki/The_Art_of_Unix_Programming https://en.wikipedia.org/wiki/The_Art_of_Unix_Programming
  • blablabla123 6y ago
    > Does this describe Unix, for example? In particular the old AT&T version, not GNU At least to me. Having all these composable commands, unimaginable through how many iterations all that stuff went. I also think that Go was created in that spirit, with robustness/conciseness being more important than anything. Although it seems the language and its philosophy is adapting to more common ways of doing things.
  • the_why_of_y 6y ago
    Research from 1995 [1] indicates that robustness was not a strength of AT&T UNIX. "The reliability of the basic utilities from GNU and Linux were noticeably better than those of the commercial systems." [0] ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf [1] ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz-revisited.pdf
• jmcqk6 6y ago
  The lie we tell ourselves is that the quality of code matters to non-engineers. It seems it doesn't. The most uncomfortable truth of our field is that there is no floor for how bad code can be, yet still make people billions of dollars. Because that's the outcome everyone else is seeking - making money. They don't care how good the code is. They care about whether it's making money or not.
  • commandlinefan 6y ago
    Well, you're not saying it right. When a non-programmer (and even some programmers) hear "bad code", they start thinking in terms of aesthetics. In fact, "bad code" is sometimes just called "ugly code", making the analogy worse. Fast, responsive code is probably "ugly" to some people, but beauty is in the eye of the beholder. Maintainable code is so verbose as to be considered "bad" to some on first glance, but proves its worth when the requirements change. Rather than talk about code quality, we should be harping on product quality, which can only be achieved through consistent software (dare I say?) engineering practices - which, if followed consistently and unapologetically, will accidentally lead to "good" code.
  • mint2 6y ago
    Haha the non-engineers at my place don’t care at all about code quality. The non-engineers also decided to write their own internal tool, with no review and zero attention to quality. It’s been outputting wrong results that will cost them a few million at least.
    • WorldMaker 6y ago
      Reminds me of the job where we'd have huge slowdowns in our massive SQL Cluster because some non-engineers in "R&D" "had" to run unoptimized, barely legible Access queries against it. We eventually had to create a replica of Production specifically for such nonsense. Well then we moved a lot more business logic that they "helped develop" that ran on a distributed platform closer to "real time" for the application, because it was very dynamic in nature, and couldn't be denormalized back into the DB and remain performant. So I had to build a new system for some of their ad hoc queries and teach them how to use it. What eventually chuffed me was realizing the "R&D" person I was "training" on the system always wore a different three piece suit every day and at least in fashion signals was probably making a magnitude higher salary than me for slower, wronger answers than any system I worked on, but probably was great at throwing it (very slowly) into very fancy graphs in Excel and useless salesmanship. There were a lot of reasons I already wasn't long for that job at that point, but that was a lasting lesson that quality and performance won't matter to certain styles of upper management.
• bsenftner 6y ago
  The result is clear, obvious code anyone can step into that is never optimized or tuned much for performance because you know some green college grad might be the person who inherits the code and you'll be under some other project's deadline and unable to help them figure out anything optimal, so it's left simple and obvious.
  • papito 6y ago
    I don't think many people spend much time on performance anymore in creation stages. Optimizing performance nowadays is purely reactive, I find.
    • bsenftner 6y ago
      Spend time working on any high compute application, and you'll spend cycles on it at every stage of the development and maintenance cycle.