this post was submitted on 09 Aug 2023
8 points (100.0% liked)

Programming Polls

129 readers
1 users here now

Welcome to the programming polls community! This is a place where you can run polls related to programming

For questions not related to being a poll theres communities such as [email protected] instead and for trivia theres [email protected]

As lemmy doesnt have a built in poll system if you want to run a multiple choice poll you can just make each option its own reply and people can vote by upvoting

founded 1 year ago
MODERATORS
all 21 comments
sorted by: hot top controversial new old
[–] Ategon 13 points 1 year ago (2 children)
[–] exapsy 5 points 1 year ago
  1. Anger management
[–] Hector_McG 1 points 1 year ago (1 children)

Pinning the client down to deciding what they actually want/ need from the software. Preferably before you’ve delivered it, not afterwards.

[–] derpgon 3 points 1 year ago

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.

[–] philluminati 10 points 1 year ago

Managing your manager and their expectations.

[–] Ategon 6 points 1 year ago (1 children)

2: Learning new technologies

[–] TheTrueLinuxDev 1 points 1 year ago* (last edited 1 year ago)

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

[–] ndotb 5 points 1 year ago

PMs and business support people with alcohol abuse disorder

[–] Ategon 5 points 1 year ago (1 children)
[–] recursive_recursion 4 points 1 year ago

finding documentation that provides examples of both "do x" and "don't do y"

[–] sizeoftheuniverse 4 points 1 year ago (1 children)

Having to deal with hype cycles. You have to play along even if deep inside you know it's stupid.

[–] Ategon 3 points 1 year ago (1 children)
[–] exapsy 3 points 1 year ago (1 children)

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.

[–] flamboyantkoala 2 points 1 year ago

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.

[–] tatterdemalion 2 points 1 year ago

Dealing with bad engineers on your team.

[–] ICastFist 2 points 1 year ago

Figuring out why my perfectly fine code isn't working as expected

[–] Phoenix 1 points 1 year ago

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.

[–] rony4102 1 points 1 year ago

People i guess?

[–] Ategon 1 points 1 year ago

1: Debugging