You must log in or register to comment.
4: Time Management
- Anger management
Pinning the client down to deciding what they actually want/ need from the software. Preferably before you’ve delivered it, not afterwards.
You don’t want the client to choose, he doesn’t want to choose either. Just tell him one is better than the other. Preferably the one that’s easier to transform to the other one if he changes his mind.
Managing your manager and their expectations.
2: Learning new technologies
It’s incredibly difficult task to master/learn an old technology or an old concept that aren’t documented well. For an example, parser algorithms are very well known for being too verbose and unnecessarily over-complicated in documentation, if you ask anyone you know in the programming community, for the next 100 people, they wouldn’t know how to implement LALR parser or Earley parser even if they graduate from university with a computer science degree.
One of the way I use to learn a concept is writing a full manual of it in LaTeX in a way that I am explaining every single aspect of it to a layman and how it can be implemented in every way as well as providing examples in C code forms. It’s a bit interesting that you sometime learn better by trying to teach it to a made up audience when writing a manual.
Example page from a book I’m current writing in rough draft:
spoiler
PMs and business support people with alcohol abuse disorder
5: Other
finding documentation that provides examples of both “do x” and “don’t do y”
Having to deal with hype cycles. You have to play along even if deep inside you know it’s stupid.
deleted by creator
3: Maintaining codebases
not if you have invested in making it scaleable. but if you’ve inherited already one from another dev then you’re probably fucked. we barely cared back then about scaleability.
It’s usually the domain knowledge that gets lost over the years that causes maintenance problems not the code or tech.
Why things are done this way gets lost. The decisions that led to it. The hard earned knowledge by the original dev team.
New team comes in and everything they do breaks something else because they don’t understand the up and downstream of their project.
Figuring out why my perfectly fine code isn’t working as expected
Dealing with bad engineers on your team.
People i guess?
1: Debugging
Commenting.
I suck at it documentation. I always forget to do it, and then I forget what the code actually does, later. Then I spend a few hours analysing my own dogshit code before scrapping the whole thing.
deleted by creator
