Ask HN: The most boring/frustrating activities during your job as a programmer?
Mine are:
- reading someone else's crappy formatted code and trying to make sense of it
- testing some small change buried deep inside the software so that I have to think very hard on how to create a UI use case where my code change is executed
- realizing, when you actually wanted to commit some changes to the repo, that you have to merge a whole bunch of other people's changes in first (and test them... and debug them...)
- after programming a week and finally finishing a "desperately needed" feature that required a partial redesign of the data model, your project leader tells you that said feature has been dropped after all
- thinking about ways of how to tell your colleagues it might be good to think about the impact of code changes in other places than just the file they are currently working an (and realizing it would be useless to tell them...) ;)
- trying to make sense of the changes someone else made to a file I once wrote and finally realizing that what he/she was trying to accomplish would have taken him 1 line instead of 20 (scattered all over the place) while still avoiding new bugs
- reading code with (obviously) misspelled variable names
- reading code that performs a very simple thing using a lot (a lot) of lines of (badly formatted) code
I am sure there are more...
14 comments
[ 4.4 ms ] story [ 46.0 ms ] thread1. Meetings
2. Waiting for an hour or so every other day before you can leave the work since you already done everything for today and don't feel like coding anymore today.
Frustrating:
1. Corruption
2. Incompetent people (see 1)
Also there are two kinds of incompetent people: those knowing (or somehow "sensing") they have "to learn a lot" and those thinking they are king (don't even know about basic CS stuff).
Also, coffee machine is too far away.
Also:
Conference calls
Being treated like garbage (by incompetent people)
700 line loops
dbo.v_TheFirstTimeIMadeThisView followed by dbo.v_TheFirstTimeIMadeThisView_1 (referencing dbo.v_TheFirstTimeIMadeThisView)
Not to mention multiple versions of stored procedures having slightly different names because they have slightly different sets of parameters -- rather than having default values on the parameters.
- Establish coding style guidelines. There should NOT be only one way, but all the different formats should be compatible in terms of feeling comfortable to read them. Also, weed out senior candidates who paid no attention to coding styles during interview.
- Establish modular codebase as much as you can.
- It happens in a big team. Modular codebase would help.
- This happens quite often in start-ups. It is part of the business and I think we must accept it.
- Hiring good engineers. Most engineers will learn, especially from their own mistakes. I admit that some people will never get it.
- Same as the last one. You can always improve it if it doesn't require much of your time.
- Refactor them.
- Try to talk to the engineer who performed the task. Most inexperienced engineers would appreciate your showing them a better way to do it. For those who don't, you can do nothing about it, except talking to the manager if it comes to the point that almost all of his/her code have to be rewritten.
- dealing with assholes
- functional testing
- writing unit tests
- extending shitty unit tests
- most programming. don't get a buzz from it anymore
I traded the buzz for the long-lasting personal software project that scratches my own itch (and probably only few people care about).