3 ms·

Please note, he got to do this working for a boss who "never even asked what produced the deliverable". This sounds like a very dysfunctional company in the fi

by rickmb 15y ago

Please note, he got to do this working for a boss who "never even asked what produced the deliverable". This sounds like a very dysfunctional company in the first place.

patio11 15y ago
So here's another reason not to call yourself a programmer: it suggests that you are a peon who needs micromanagement. At Japanese megacorps, which are not historically known for huge degrees of flexibility, it is assumed that Software Engineers should be able to tie their own shoelaces without needing to be told what kind of knot to use. The boss asked for me to produce comprehensible and comprehensive documentation of 100,000 lines of Perl and gave me a two month deadline. I produced what he asked for in two weeks. The production of this involved a Ruby script. Contra many sibling comments, delivering a higher quality product earlier than the deadline does not typically result in one getting fired, particularly when one makes a habit of making your boss look like an effing genius for managing you so well.
- rewind 15y ago
  My take on what you said in the article was that you were encouraging developers to implement software (that was not tied into other software, but that was still used by end users) in a language that they want to learn. From what you said here, it sounds like you mean something you run just for yourself to get your work done, then toss. I thought you were suggesting doing this for actual software that is used internally or by a client, but that had no other dependencies and you could work on by yourself; as in software that may need to be maintained, have bugs that users discover that need to be fixed, etc. If you mean software for your own purposes as a tool to get a project done, but is not used at all once the project is done, and nobody will need to know or care that it existed, then my comment does not apply to that and I'm mistaken on my interpretation of your original meaning. If you mean software that is used more than once internally or by a client and you're writing it in a language that someone has to support that is NOT supported by the company you work for, then my original opinion stands ;-) Either way, the parent to your comment has no bearing on my original comment or this one. You replied here, so I'm just replying to you.

by rickmb 15y ago

Please note, he got to do this working for a boss who "never even asked what produced the deliverable". This sounds like a very dysfunctional company in the first place.

patio11 15y ago

So here's another reason not to call yourself a programmer: it suggests that you are a peon who needs micromanagement. At Japanese megacorps, which are not historically known for huge degrees of flexibility, it is assumed that Software Engineers should be able to tie their own shoelaces without needing to be told what kind of knot to use. The boss asked for me to produce comprehensible and comprehensive documentation of 100,000 lines of Perl and gave me a two month deadline. I produced what he asked for in two weeks. The production of this involved a Ruby script. Contra many sibling comments, delivering a higher quality product earlier than the deadline does not typically result in one getting fired, particularly when one makes a habit of making your boss look like an effing genius for managing you so well.

rewind 15y ago
My take on what you said in the article was that you were encouraging developers to implement software (that was not tied into other software, but that was still used by end users) in a language that they want to learn. From what you said here, it sounds like you mean something you run just for yourself to get your work done, then toss. I thought you were suggesting doing this for actual software that is used internally or by a client, but that had no other dependencies and you could work on by yourself; as in software that may need to be maintained, have bugs that users discover that need to be fixed, etc. If you mean software for your own purposes as a tool to get a project done, but is not used at all once the project is done, and nobody will need to know or care that it existed, then my comment does not apply to that and I'm mistaken on my interpretation of your original meaning. If you mean software that is used more than once internally or by a client and you're writing it in a language that someone has to support that is NOT supported by the company you work for, then my original opinion stands ;-) Either way, the parent to your comment has no bearing on my original comment or this one. You replied here, so I'm just replying to you.