garyharan/experience.txt

## experience.txt
A friend of mine, approaching 50, works as a programmer in a medium sized consultancy. In a recent conversation he told me how he felt like he was feeling older now that they had hired many 20-somethings in his company. The younger developers, he said, would do things faster than he would and it started to look like he was just a slower developer than the more youthful new hires. He was wondering if his days were numbered.

He was resigning himself to the idea that he was experiencing some kind of decline of his faculties if he compared himself to the more youthful years of his career. However this wasn’t the only conversation I had about the work at his company.  The conversation before that one had him put the finger on something crucial.

So I had a conversation with him about it and we connected the dots.

Me: What was the password story they tackled?
Him: A password reset.
Me: And what was wrong with how they implemented it.
Him: Well the user typed their email in and then if they click the “forgot password” link they’re sent to another form where they’re asked with a blank text input to fill out their email again.
Me: And what did you do differently?
Him: Well I added a bit of javascript so that the email was pre-filled as a parameter and that it was just a question of confirming the email in the next page instead of typing it again.
Me: So you thought of something the quicker junior didn’t that made it easier for the end user?
Him: Yeah I guess so.

Then another feature:

Me: What about the scheduling limit where a user could only use the feature once a day?
Him: Oh the junior made it so that the user could only use the feature 24 hours after having used it.  So if they used it at 13h46 that day they would be told “Sorry you can only use this feature once a day” until 13h47 the next day.
Me: And you fixed it how?
Him: I made it so that the feature just looked at the day and not waited an arbitrary 24 hours.  The junior’s way forces the user to use it only later each day than he had the previous day.  Good luck if they used the feature at 23h59!
Me: So even though the junior pushed the feature out quicker there was a bug in it that would only become immediately apparent to some users and would eventually become a problem for every user?
Him: Yeah I guess so.

This was clearly a case of implementation details bleeding out to the end user and it was a naive one.  A more experienced team would have discussed the reason for the feature and looked at it from a product perspective before reaching out for an implementation. Writing code before the crucial conversations are had means you lock yourself into an implementation.

The conversation continued:

Me: What about that bug where the password could be inputed in uppercase or lowercase and it wouldn’t matter.
Him: Yeah that one wasn’t a bug but the CMO asked the junior if he could make it a feature!
Me: So how did you tackle that?
Him: Well I caught it in a code review and had to explain to the junior and the CMO why that was making things less secure.
Me: So you stopped a security issue from happening and educated 2 people about how not every feature is a good feature?
Him: Yeah I guess so.

Although my friend and I know that the more characters you can make use of the more secure your password can be the CMO had to be explained this and the junior had to be sensibilized over this.

I see these things as bugs and they appear everywhere on the web.

For example some big names where I live:

Desjardins forced until recently their password to be 7-8 characters and these had to start with a number. Some of those older passwords are still in use today even though the bank’s new password format has since changed.  At least they don’t send you the password via email like some banks have been known to do in the past.

Loto Quebec only allows you to do a deposit once a day after 24 hours of the previous deposit. Exactly as the bug above is described.

St-Hubert BBQ does not allow any characters aside from non-accented letters and numbers in their feedback form. So as you can imagine in a mostly francophone province how accents might actually be useful.  Not that that feedback form goes anywhere useful… I’ve told them countless times that there needs to be a way to say no cheese on one item on their kid’s menu.

If this does not underscore the importance of a diverse team I don’t know what does. The lack of accented characters on the St-Hubert feedback form wouldn’t have been picked up by someone entirely anglophone but a francophone would surely have tested it with some as matter-of-factly as they would typing out any test data.

So for all my friends out there who feel like they’re not valued… maybe you should move on to a team that values having a wider scope of considerations.  If you’re working on low stakes menial work perhaps your value isn’t being recognized the way it should be because you’re thinking of way more things than your client cares for.
	A friend of mine, approaching 50, works as a programmer in a medium sized consultancy. In a recent conversation he told me how he felt like he was feeling older now that they had hired many 20-somethings in his company. The younger developers, he said, would do things faster than he would and it started to look like he was just a slower developer than the more youthful new hires. He was wondering if his days were numbered.

	He was resigning himself to the idea that he was experiencing some kind of decline of his faculties if he compared himself to the more youthful years of his career. However this wasn’t the only conversation I had about the work at his company. The conversation before that one had him put the finger on something crucial.

	So I had a conversation with him about it and we connected the dots.

	Me: What was the password story they tackled?
	Him: A password reset.
	Me: And what was wrong with how they implemented it.
	Him: Well the user typed their email in and then if they click the “forgot password” link they’re sent to another form where they’re asked with a blank text input to fill out their email again.
	Me: And what did you do differently?
	Him: Well I added a bit of javascript so that the email was pre-filled as a parameter and that it was just a question of confirming the email in the next page instead of typing it again.
	Me: So you thought of something the quicker junior didn’t that made it easier for the end user?
	Him: Yeah I guess so.

	Then another feature:

	Me: What about the scheduling limit where a user could only use the feature once a day?
	Him: Oh the junior made it so that the user could only use the feature 24 hours after having used it. So if they used it at 13h46 that day they would be told “Sorry you can only use this feature once a day” until 13h47 the next day.
	Me: And you fixed it how?
	Him: I made it so that the feature just looked at the day and not waited an arbitrary 24 hours. The junior’s way forces the user to use it only later each day than he had the previous day. Good luck if they used the feature at 23h59!
	Me: So even though the junior pushed the feature out quicker there was a bug in it that would only become immediately apparent to some users and would eventually become a problem for every user?
	Him: Yeah I guess so.

	This was clearly a case of implementation details bleeding out to the end user and it was a naive one. A more experienced team would have discussed the reason for the feature and looked at it from a product perspective before reaching out for an implementation. Writing code before the crucial conversations are had means you lock yourself into an implementation.

	The conversation continued:

	Me: What about that bug where the password could be inputed in uppercase or lowercase and it wouldn’t matter.
	Him: Yeah that one wasn’t a bug but the CMO asked the junior if he could make it a feature!
	Me: So how did you tackle that?
	Him: Well I caught it in a code review and had to explain to the junior and the CMO why that was making things less secure.
	Me: So you stopped a security issue from happening and educated 2 people about how not every feature is a good feature?
	Him: Yeah I guess so.

	Although my friend and I know that the more characters you can make use of the more secure your password can be the CMO had to be explained this and the junior had to be sensibilized over this.

	I see these things as bugs and they appear everywhere on the web.

	For example some big names where I live:

	Desjardins forced until recently their password to be 7-8 characters and these had to start with a number. Some of those older passwords are still in use today even though the bank’s new password format has since changed. At least they don’t send you the password via email like some banks have been known to do in the past.

	Loto Quebec only allows you to do a deposit once a day after 24 hours of the previous deposit. Exactly as the bug above is described.

	St-Hubert BBQ does not allow any characters aside from non-accented letters and numbers in their feedback form. So as you can imagine in a mostly francophone province how accents might actually be useful. Not that that feedback form goes anywhere useful… I’ve told them countless times that there needs to be a way to say no cheese on one item on their kid’s menu.

	If this does not underscore the importance of a diverse team I don’t know what does. The lack of accented characters on the St-Hubert feedback form wouldn’t have been picked up by someone entirely anglophone but a francophone would surely have tested it with some as matter-of-factly as they would typing out any test data.

	So for all my friends out there who feel like they’re not valued… maybe you should move on to a team that values having a wider scope of considerations. If you’re working on low stakes menial work perhaps your value isn’t being recognized the way it should be because you’re thinking of way more things than your client cares for.