プログラマーの苦労

原因不明のバグに出会う

プログラミングの世界には、「プログラムは思ったように動くのではない。書いたように動く」という有名な格言があります。

しかし、いざプログラマーになったとき、頭ではこのことを理解していても、まったく思惑通りに動作せず、原因がなかなか掴めない場合の苦労は、本当に厳しいものがあります。

仮に、これがすでに運用しているシステムで致命的なバクの場合は、徹夜してでも原因を究明しなければなりません。

気持ちも焦ってしまい、さらにバグの原因も掴めないという悪循環に陥ります。結局、原因が単純なミスだったときの徒労感は、計り知れないものがあります。

プログラマーは、こうした焦りやプレッシャーとも日々戦わなくてはなりません。

読めないプログラムがある

プログラマーは、他人が書いたプログラムを読み、スキルを高めることも大切です。しかし、いざ他人の書いたものを読んでみると、反面教師になる場合が多いともいわれます。

それは、その内容が何をしたいプログラムなのか理解できないケースも多いからです。

通常、プログラミングは「誰が見てもわかりやすい」というのが大前提です。それを無視して、自分勝手にプログラミングしてしまうと、他のスタッフや後継者が悩むだけで何ひとつ良いことはありません。

複雑にしたくてしたわけでなかったとしても、それがバグを生み、無駄な修正を重ね、さらに複雑化し…と悪循環に陥ってしまうことも現場ではよくあります。

自身がプログラマーとして成長するうえでは、できるだけ読みやすいプログラミングをする努力をしなくてはなりません。

タイトなスケジュールで仕事をしなくてはならない

開発するうえで、スケジュールを組んで動くことはプログラマーとして当たり前ですが、通常、大まかなスケジュールはシステムエンジニアなり、プロジェクトマネージャーなりが決めます。

その組み方が、企業によっては「1日10時間労働」といった長時間のスケジュールで組む場合もあります。しかし、そもそもが残業ありきで組まれてしまうと、破綻するのは目に見えています。

1日実働8時間の職場であった場合、1日2時間の残業であれば一見たいしたことなさそうに見えるかもしれませんが、1回でもイレギュラーなことが残業時間はどんどん増えていきます。

残念ながら、現場で開発をするプログラマーは、このようなイレギュラーなことに遭う確率も高いのは否めません。

どうしてもタイトなスケジュールのなか、仕事をしなくてはならず、心身ともに疲れが溜まってしまうこともあります。

仕事体験談