
Ask HN: The most boring/frustrating activities during your job as a programmer? - kluck
Title says it all.<p>Mine are:<p>- reading someone else&#x27;s crappy formatted code and trying to make sense of it<p>- 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<p>- realizing, when you actually wanted to commit some changes to the repo, that you have to merge a whole bunch of other people&#x27;s changes in first (and test them... and debug them...)<p>- after programming a week and finally finishing a &quot;desperately needed&quot; feature that required a partial redesign of the data model, your project leader tells you that said feature has been dropped after all<p>- 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...) ;)<p>- trying to make sense of the changes someone else made to a file I once wrote and finally realizing that what he&#x2F;she was trying to accomplish would have taken him 1 line instead of 20 (scattered all over the place) while still avoiding new bugs<p>- reading code with (obviously) misspelled variable names<p>- reading code that performs a very simple thing using a lot (a lot) of lines of (badly formatted) code<p>I am sure there are more...
======
muddyrivers
My ways to stay positive:

\- 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.

~~~
kluck
Thank you for the ideas ;) At heart I am a realistic optimist. Some people
will never learn and some things never change.

------
romanovcode
Boring:

1\. 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)

~~~
arnold_palmur
I had 6 meetings totally 4 hours last Friday (granted I work for a large
bank), but it's causing me to reconsider if I really want to be here.

~~~
kluck
You could write a small program that, everytime some calculation is done with
money, cuts of the remaining fractions of cents and puts them into your bank
account. Over time it will be a lot of money and no one will notice ;)

------
fisle
Mine is waiting for ElasticSearch reindex after changing one number to see
actual difference in fuzzy-matched search results. 7 minutes is a long time
when you need to do it multiple times a day. (While I am typing this,
ElasticSearch is reindexing - again)

Also, coffee machine is too far away.

~~~
kluck
Yes, reindexing ES is a pain in the ass. While it is reindexing, I constantly
stare at the screen asking myself "Why the f* do you have to reindex, I just
added a field to the mapping you f* piece of sh* moronic database".

------
floppydisk
Email and being expected to read every email as soon as it arrives and craft a
perfect response in a timely manner while hitting all deadlines. Then, if you
don't answer quickly, three people come swinging by your office asking if
you've "seen that email" yet.

------
Stoo
Working on a component / module / piece of functionality and now you're _the_
person to turn when it doesn't work. Even though a dozen other people have
worked on it and it's changed completely since you last saw it.

------
heynickc
+1 for Meetings!

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)

~~~
insoluble
>dbo.v_TheFirstTimeIMadeThisView followed by dbo.v_TheFirstTimeIMadeThisView_1

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.

------
bbcbasic
\- over complicated human processes

\- dealing with assholes

\- functional testing

\- writing unit tests

\- extending shitty unit tests

\- most programming. don't get a buzz from it anymore

~~~
kluck
\+ for writing unit tests ;)

I traded the buzz for the long-lasting personal software project that
scratches my own itch (and probably only few people care about).

