• 0 Posts
  • 15 Comments
Joined 1 year ago
cake
Cake day: July 2nd, 2023

help-circle




    1. Those apps are simple
    2. Those apps target a wide audience, hence have more budget as a result
    3. Those apps are made by large, well oiled (you’d hope at least) companies. You don’t want my honest opinion on most small software development boxes. This industry grew faster than mentors became available for the newbies, so many devs including seniors still don’t know what they are doing.


  • SolarMech@slrpnk.nettotumblr@lemmy.worldEnough IS enough
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    8 months ago

    Not even. Billionaires don’t want you to have money because if you did you’d have bargaining power and the ability to turn down jobs you don’t like, well, you’d turn down jobs you didn’t like. Or at least work fewer hours.

    So long as you need some sort of job, you’ll do some work for them or those who work for them (essentially supporting their structure) rather than for others in your community for that sake (ie: earning less money to do a job you relate to more, which I think a lot of us would naturally do instead of working for corporations).

    So long as someone is having trouble paying rent, they’ll do jobs they otherwise would have considered degrading or unconscionable.

    So long as someone is stuck in the street without a home or job and hardly able to get food, and we see him, we’ll work twice as hard to make sure we don’t end up like that.

    This is why they don’t give us money. Material need is a lever of control, that keeps their power intact.



  • Learning to deal with “unmaintanable” codebases is a pretty good skill. It taught me good documentation and refactoring manners. It’s only a problem for you if management does not accept that their velocity has gone down as a result of tech debt pilling up.

    Code should scream it’s intent (business-wise) so as to be self-documenting as much as possible As much as possible is not 100%, so add comments when needed. Comments should be assumed to be relevant when written, at best. Git comment should be linked to your work ticket so that we can figure out why the hell you would do that, when looking at the code file itself. I swear some people seem to think we only read them in PRs (we don’t). Overall concepts used everyday, if they need to be reexplained, should probably be written down (at least today’s version). Tests are documentation. Often the only up to date one?


  • Git wasn’t used all that much in the 2000s. As far as I know it became popular in the 2010s (though it was always a thing in some circles I think) and then just supplanted almost everything else.

    Also keep in mind some shops tend to follow larger tech companies (microsoft, etc.) and their product offering. So even new products might not have been on git until MS went in that direction.



  • Generally, you can replace some comments with variable names or comment names. Which means you must already be in the habbit of extracting methods, setting new variables to use appropriate names, and limit context to reduce the name (Smaller classes and methods means shorter names can be just as expressive, because the context is clearer). It lowers the number of wtfs per minute you get reading code before you even need whole sentences to explain why things are done in a certain way, because the names can be a powerful hint.

    But realistically, you end up needing comments for some things anyways.


  • That said, working from home has so far saved me a lot of both time and money. This is a thing to consider as an employee when considering who to work for (or if your boss takes it away, if you still want to work there after essentially having a benefit revoked unilateraly).

    Public transit pass. Actual time for transit which for me was around 90 minutes a day (7.5 hours a week!), more complex lunch logistics (time or money), etc.

    A quieter workplace, no need to book rarely available rooms to take calls/meetings. There were upsides.

    My first remote job had almost no issues at all. We already knew each other and we still took time to discuss issues via calls. New job not so much. We tend to be pressed for time so only focus on obvious “work” and then works suffers because of a lack of communication/common vision.



  • It has a rocky start, and a lot of cruft from that era sticked around.

    There are also a lot of horrible legacy projects from the pre-ES5 era which are a pain to work with. Often older projects were coded either before people knew how to do javascript right, or before the devs who wrote it knew how to write javascript right.