you are viewing a single comment's thread
view the rest of the comments
[–] 0 points 3 months ago (1 child)

For me, that is all integrated part of "programming". You missed the documenting the code part, but i consider this as an oversight.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 9 points 3 months ago* (last edited 3 months ago)

    It says a lot that you think a coding good practice like "documenting things in code" which is at the level of using descriptive variable and function names, should be in the same bucket as structural non-coding processes (which are often entire professionions or very senior professional branches) like Requirements Analysis or Technical Architecture, both highly-complex things (the latter being the very top in seniority of the technical career track) which are non-existent in a formal sense in improvisational (read: amateur as fuck) "programming" companies.

    You're making my point on the whole Dunning-Krugger thing.

  • source
  • parent
  • [–] 4 points 3 months ago* (last edited 2 months ago)

    Not only in code. Documentation for the end user (or at least halfway there, the final document is done by a separate department), is important, too.

    There is a reason that my job description is "Embedded Systems Architect". But I see this complete packet as "programming".

  • source
  • parent
  • [–] 1 point 3 months ago* (last edited 3 months ago)

    You missed the documenting the code

    Your words.

    As for your job title, don't take this badly but "Systems Architect" is not at all the same as "Technical Architect".

    If you're actually designing or at least tuning software development processes and coding standards across multiple teams (so, not just optimizing how teams work but also optimizing cross-team work), you're a Technical Architect.

    A Systems Architect, when the title is properly used, just means that you're designing software whose operation spreads across multiple platforms (so, for example, multiple tiers in a multi-tier system).

    Also there is quite a range in Systems Architect - knowing how to code in two or more platforms (say, STM32 and some Android, to make a bit of home electronics with a microcontroller be controllable from a smartphone) is not at all the same as knowing how to design a high-performance distributed system running in multiple machines, integrated with multiple external system working for ten/hundred of thousands of client front-ends and supporting things like Distribute Transactions so that any failures don't leave half-complete operations.

    You can be a Systems Architect and be isolated form most of the concerns of the software development out there. especially if you're a team of one developing the software side of products based on some marketing person's idea of what customers supposedly want.

    Unsurprisingly, Technical Architects are non-existent outside large companies and even there they're pretty rare.

    Again, still making my point on Dunning-Krugger.

  • source
  • parent
  • load more comments (-1 replies)
  • [+] 3 points 3 months ago
    [removed by mod]
  • source
  • parent
  • [–] 1 point 3 months ago (-1 children)

    Oh, they "come home to roost" almost immediately - you just don't see it because whole teams are doing everything they can to hide it or ignore it - nightly manual data update statements, etc.. Here's just one real example.

    In my last (read: final) job as a senior software engineer, I discovered dozens of serious problems with the system I was assigned to "maintain". They ignored all of them - wouldn't let me fix anything. Meanwhile I was responsible to solve production problems on the daily (duplicate data, insert failures, performance slow-downs, etc).

    It wasn't long before the fact those problems weren't going away that they became problems I "caused". Meanwhile, all the fixes I wanted to make were ignored. I had one problem I dissected and and gave my boss a brief write-up of the scenario. He told me I needed to do deeper analysis. When I came back a few hours later with a considerably more detailed explanation, he didn't read it and complained of a "wall of text", which he literally told me to write. Then he created a random-number hack to "fix" the problem.

    They did not grasp the concept of data normalization and primary keys as they had one particular table that represented two levels of detail (for example, account -> order). They put both in one table and had a code based special update to the "account" number so they would not get a PK violation rather than just fix the data structure.

    They had as single database connection open all the time to handle all inserts in a singleton service, then launched as second one on the same database to process messages faster - and couldn't understand why it didn't double performance.

    The main routine had a cyclomatic complexity of 360! I shit you not! And everybody agreed it was "95% working" even as we continued manually fixing (the same) problems daily.

    Week after week, the customer (internal) would raise more data issues as "new" problems. I'd routinely ask two to three questions about the data set and explain that's the same problem that's been going on for six months, and if we could just get my PR reviewed, we can test it and deploy it.

    All these problems were in a single service.

    I was let go not long after the 1 month probation they soon initiated and told I was not performing at the level of a senior developer.

    This is how delusional these people are. They refuse to acknowledge their flaws even after hiring someone specifically to solve them. They blithely call their monstrosities "successful" while committing many staff to late nights and weekends "managing" it.

  • source
  • parent
  • hideshow -1 child comments
  • [+] 1 point 3 months ago
    [removed by mod]
  • source
  • parent
  • [–] 1 point 2 months ago (-1 children)

    It was, except for the fact of ageism, the shortness of the tenure, the already accelerating developer job apocalypse, and the soul crushing insult of the experience. After a year, I stopped looking for a job and felt a huge weight lift off my soul. My career is dead, and I stopped searching when I realized I lost all joy in the craft. I just didn't want to do it anymore. It is almost like the way Alex in A Clockwork Orange could no longer listen to his favorite musician, Bach, after his "programming". I find myself recoiling from it.

  • source
  • parent
  • hideshow -1 child comments
  • load more comments (-1 replies)
  • load more comments (-2 replies)
  • load more comments (-2 replies)