ADHDエンジニアのL2キャッシュ

ADHDの能力を駆使して自由な発想を落としていくよ

ADHDを克服した話

2年前にADHDと診断されてから紆余曲折あった。 今は殆ど気にせず過ごしている。

1. ADHDの症状は治ったのか?

まるで変わっていない。 相変わらず忘れ物は多いし、時間間隔は殆ど無いし、人の話は全然頭に入ってこない。

ただただ気にしないことにしました。

2. 周囲との摩擦を解消した話

本人が気にしなくてもADHDの症状により仕事関係において様々な問題を引き起こす場合があります。 特に職場に『普通依存症』の患者がいる場合。

NEC系列の会社に努めていた頃プロジェクトリーダーがそんな人だったので、その時摩擦を解消した方法を記載します。

2.1. 『普通』攻撃をとりあえず無視してみた

普通依存症患者は「普通はこうだ」と主張すれば意見が通ると思っています。 ということで私は普通ではないので「はぁ……そうですか」と全部右から左に受け流すことにしました。

結果プロジェクトリーダーとの中が険悪になりました。

2.2. ヒアリングしてあげる

しょうがないので「普通は分かるだろ」とイライラしているリーダーに何度も「つまりこういうことですか?」と訪ねに行きました。 しかしそのたびに大変イライラしていた様子で、「そんなこともわからないのか」「普通に遣ってくれればいいんだ」としか返してこない。

埒が明かないので別の手段を考えることにしました。

2.3. 距離を取ってみる

まともにコミュニケーションが取れないままストレスが限界に到達したので関係を切断することにしました。 対話できないなら切断するのが一番合理的な戦略です。

ということで直属の上司に異動の希望を出しました。

しかし、のらりくらりと交わされていつまでたっても異動の話は来ませんでした。 もう限界と言ったはずなんですけどねぇ。

2.4. 環境ごと変えてみる

異動の話が引き伸ばされている間に同時進行していた転職活動が実を結びました。 というわけで職場ごとララバイしました。

新しい職場には普通依存症患者がいなかったのでだいぶ快適に過ごせています。 ちゃんと自分の頭で考えて説明やら行動しているんですね。

3. 投薬治療の中止

普通を押し付けてくる人がいなくなったので、無理に普通の人に合わせる必要もなくなりました。 というわけで投薬していたストラテラを3ヶ月ほどかけて減薬していき最終的には必要なくなりました。

※減薬は医師と相談のうえ行いましょう

まとめ

ADHDの人が苦しい思いをするのは、周囲に普通依存症の人が居るからじゃないでしょうか? 「普通はこうだ」という観念に依存してしまうと、そのルールに則らない人を平然と迫害してしまいます。

話して分かる人ならいいのですが、そうでない場合は関わる時間が全て無駄になります。 他人が変わることに期待するよりも環境を変えるのが近道なんじゃないでしょうか。

プログラミングにおける様々なstaticまとめ

コード書いてる時にちらほら見かけるstatic
こいつらっていったいなんだっけ?

staticメモリ

プログラムが扱うメモリは大きく分けてstatic/stack/heapの3領域あります。

  • static: あらかじめ予約されたサイズ固定の領域
  • stack: 動的に確保できる領域。スコープが決まっており、そこを抜けると強制的に解放される。高速
  • heap: 動的に確保できる領域。任意のサイズ、任意の順で確保開放できる。低速。

ここでいうstaticと言うのは「プログラム全体を通してstaticに確保されるメモリ」という意味です。
プログラムした時点でサイズが決定し、プログラム起動時にまとめて確保されてしまいます。

C言語では以下の2つが該当します。

  • global変数
  • 関数内でstatic宣言された変数

大概はheapで確保したメモリへのポインタをglobal変数に格納するという合わせ技で使われます。
ちなみにstack変数のポインタを格納しても勝手に開放されるので意味ないです。と言うかバグです。

コンパイル単位制限

C/C++でしかお目にかからない構文です。

  • global変数の頭につける(global static変数)
  • 関数宣言の頭につける(static関数)

数あるstaticの中で一番意味不明な振る舞いをします。

最近はスクリプト言語が多いので忘れがちですが、プログラムは以下のステップで作成されます。(末尾はC言語の場合の拡張子)

  1. ソースコードにテキスト処理を施す(プリプロセッサ
  2. ソースコードからオブジェクトファイルを作る(コンパイル
  3. オブジェクトファイル同士を静的に結合してライブラリにする(静的リンク)

global変数や関数はスコープが無いため、同名があればコンパイル時、静的リンク時にエラーになってしまいます。 しかしstatic宣言をすることで、その名前はコンパイル時にしか使用しませんよ、という制約を加えることができます。 (つまり静的リンク時に衝突しない)

インスタンスに対してstatic

多分一番お目にかかるstaticです。
クラスのメンバに付与することで効果を発揮します。

staticフィールド

本来クラスはインスタンスの雛形で、フィールドはインスタンスごとに固有のメモリ領域を持ちます。
しかしこのstatic指定を追加すると、フィールドはインスタンスではなくクラスで管理され、全インスタンスで共有されます。
オブジェクト指向とは何だったのか。

staticメソッド

staticフィールドのみにアクセスし、通常のフィールドにアクセスできないメソッドです。
引数だけで結果が確定する関数などでも使用されます。

staticクラス

staticなメンバしか保たないクラスの宣言に使います。 基本普通のクラスなんですが「どうせ全部staticなのだからnew禁止しといてあげるね♪」というおせっかいがつきます。

まとめ

ややこしくて仕方がない。
違う概念に同じ名前をつけるの辞めてほしいですね。

急いでガチャガチャと組み込んだコードはコケる

今日の学びシリーズ。

当たり前の結論なんですが全然動いてなかったです。

なんですけど、試しに回した時はタスク実行ログには完了フラグが立っていて、静かにおなくなりになっていたので見落としていました。

※テストフェーズで発覚したのでリリースはしていません。

Issueが仲間になりたそうにこちらを見ている

歩いていると道にバグが落ちている。

よくあることですよね。

バグと言わないまでもこうした方が良いんじゃないかとか有ると思います。

そんな時しれっとついでに改修できれば最高にCOOLですが、それでバグったら最高にFOOLですね。

そんなBOOLの世界で大概TOOLは言うことを聞いてくれないのでPOOLしておくのが正しい決断なのだなと思いました。

ログ大事

ログと言ってもいくつか有るんですが、一番親プロセスの吐くログにはエラー出てなかったんですね。

子供がちゃんと怪我せずに帰宅したのかちゃんと見とけよ、ネグレクトかよ、とか思いましたが、子供はきっちり例外ログ吐いてました。

ちゃんとログを全部見ろという当たり前の話。

Revertも手間

まとまったコミット積んでるなら素直にRevertすればいいだけなんですが、間にマージが入ったりして、なんだかよくわからない網目構造になっていました。

もはや履歴を追いかける気力はなく、masterとのdiffを確認しながら切り離しにかかるというなんか手間なことをしました。

まとめ

君子危うきに近寄らず。

優先度というものが有るので時にそっとしておくことも大事。

でも記録は残しておこう。

会議には目的を

今日から始まった「今日の学びシリーズ」第一弾はコレです。

最悪なのは目的がないこと

会社で過ごす時間のうち最も無駄な時間が「目的のない会議」です。

さて言われるがままに、もしくは慣習どおりに人を集めたが何を話し合おう?

毎週、毎月予定は入れているが、何を話し合うかはっきりしない。

なかなかそこまで酷い会議はないとは思いますが、有るならきっと大きな(闇の)力でそこに固定されています。

心してかかりましょう

ゴールがはっきりしない

会議の目的が「レビュー」とか漠然としたままではないですか?

準備を疎かにするってこういうことだと思います。やらかしがち。

今日テスト設計書のレビュー突っ込んだんですが、明確なゴールポイントをハッキリイメージしていなかったので初手で赤ゲージまで削られました。

といっても、レビューなのでおおよそ問題点の洗い出しができたので何とかかんとかなりました。

ゴールを掲示していない

予定表に入れる時点でゴールポイント書いときなさいという話ですね。

文章に書き卸しておくと、議題が行方不明になる心配もないですし、任意参加者も参加の判断がし易いというもの。

まとめ

ゴールをハッキリ明記してから会議始めるの大事

ADHDが編み出した相手の言葉の真意を汲み取る方法

筆者はADHDのため、相手の言葉をよく聞き、汲み取るのが余り得意ではありません。

しかし才能は経験によって補填することができます。

これまでの経験から頭を使って相手の会話から効率的に情報を抽出する方法についてまとめます。

情報を3つに分ける

会話に載せられている情報は大きく分けて以下の3つに分けることができます。

  • 事実
  • 要求
  • ノイズ

上から順に情報な重要です。

事実

客観的な情報です。

これだけ拾っていれば基本的には困りません。

ただし一見事実のように見えてもノイズの情報は多いので以下の情報を特に信用すると良いです。

数値などで比較できる情報

  • 売上が下がった
  • 100点を取った

本人の内面情報

  • 嬉しい/悲しい
  • やりたい/嫌だ

要求

命令系/依頼系/質問形のいずれかの構文で飛んできます。

命令形 「1週間以内に報告しなさい」 依頼系 「後日お電話で相談させてください」 質問形 「席を譲って戴けませんか?」

この構文から外れた「暗に要求」というのがありますが、基本的に無視していてもそんなに困りません。

事実関係を整理したあとで明示的にこっちから質問をしてやればこの回収できる情報なので優先度は低いです。

要求の対応

要求を出されるとそれに応じなければならないと思いがちですが、別にそんなことはありません。

一方を立てればもう一方がたたず、なんてことは非常によくあることですし、 そもそも本人が言葉で要求していることと、本当に必要としていることは余り一致しません。

事実情報をもとに行動を決定する際の参考情報として機能します。

ノイズ

価値のない情報です。 見極めが難しいですが、一見重要そうな情報でもこちらに属することがたたあります。

  • みんないってる
  • 私は反対したんですけど
  • ボケ/アホ/間抜け
  • いい加減にしろ
  • 完璧に
  • 普通に
  • ちゃんとする/しっかりする
  • おい/こら
  • 許されない
  • 悪い/良い

例えば

「おい!いったいいつになったらちゃんとするんだ!いいかげんにしろ!!そんなやり方許されないぞ!」

といった発言はノイズのみから構成されます。

ノイズの対応

基本的に解釈しなくても問題ないです。

重要な情報は含まれないですが、会話の楽しみを司る部分でも有るので余裕がある時は解釈して楽しむと言いでしょう。

まとめ

会話はリアルタイムで情報が飛んで来るので処理が大変です。 なので事実情報だけを抜き出して、他の情報は後から拾うようにすると捗ります。

企業のブラックリスト

自分が今後関わりたくない事業者の一覧をメモしておきます。
追記していきます。

可能な限り利用を避ける事業者

ヤマダ電機

強引なものの売り方が気に入らない。

ブラック企業大賞2014』で大賞を勝ち取った輝かしい経歴を持つ。
職場もブラックらしくKill-Count数も結構稼いでいる。

ダイキンからエアコンを卸してもらえないなど、メーカーに対してもなにかあるようだ。

日経BP社のアフターサービスランキングでも最下位を記録した上に、逆上して日経BP社を訴訟するという堂々たる風格。

私自身の体験からしても店員の対応が無責任で信用できない。
レジを通すことさえできればよいという考えが透けて見える。

売上至上主義に取り憑かれた20世紀の負の遺産

同じ量販店ならばヨドバシカメラを推したい。
商品知識が桁違いで、しかもモノ売る気あるのかと疑わしいくらい営業してこない。ほんとうに必要なものが買える。

また、商品説明が不要ならば通販を使ったほうがいいだろう。