|
Yeah the code samples are perfectly readable, obviously you need to type them out but this isn't a bad thing.
|
|
|
|
|
|
Most things are readable on Kindle, I have a variety of books on mine. And the bonus is that you can get a Kindle reader for your PC and iPad so you have a variety of places to read it from.
|
|
|
|
|
I usually read technical books using the kindle app on my tablet. They format horribly on an actual kindle. I usually get them here, there are a ton of free ones: http://it-ebooks.info/tag/programming/[^]
|
|
|
|
|
I created part of a web app. Another dev went in and changed how some code works and a modal dialog stopped working (it shows as an empty modal with only the title, but underneath there's an exception). Guess who was assigned the bug? Of course the creator of the tool, that would be me. This happens from time to time and I hate it. I feel that whoever breaks stuff should be publicly shamed (for example in the CI server's website, but of course my client doesn't have CI...) and responsible for fixing it. I am sure this was discussed a dozen times here, sorry. This really grinds my gears.
|
|
|
|
|
Ahem. With colleagues, always praise in public and criticize them in private (i.e., to them and not just talking about them behind their back).
|
|
|
|
|
This is good advice. Maybe unless they never listen to you.
|
|
|
|
|
I'm with Pete on this one, as I see team work more valuable than being the sole star in the eyes of manager. However with that said it depends mostly on the team AND the manager.
If your teammate doesn't care (again?) then definitely bring it to your manager. If he also doesn't care... well... I would say time for a new job.
In a company I worked for a while ago, management added mandatory field to bugs in JIRA - you had to choose from the list of devs who caused the bug. Needless to say it didn't work very well in the long run...
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
Pete O'Hanlon wrote: With colleagues, always praise in public and criticize them in private
I sit on both sides of the fence with this one. I agree because it fosters better working relationships, but I disagree because it frequently creates an illusion of competency, especially to management and new co-workers.
The only way out of this that I've found is to take Dale Carnegie's approach of combining some positive aspect with a necessary criticism. Though it sometimes is damned hard to find something positive other than "Joe worked really hard on this but unfortunately, all his hard work had to be thrown out the window."
Personally, I wish we didn't have to "handle" people with velveteen gloves. That, and position and salary should be determined by one's peers (with, of course, the subject's evaluation of the ability of others to evaluate him/her as part of the equation.) *evil grin*
Marc
|
|
|
|
|
Excellent advice! Not surprised though, coming from you.
|
|
|
|
|
|
Yeah, that came as a shock to me too. Until this point, I thought you were the sole cause of all bugs.
|
|
|
|
|
Must be my minions spreading my legend i guess
»»» <small>Loading Signature</small> «««
· · · <small>Please Wait</small> · · ·
|
|
|
|
|
|
Like Windows Vista
»»» <small>Loading Signature</small> «««
· · · <small>Please Wait</small> · · ·
|
|
|
|
|
I thought Vista was a virus. I tried installing XP but Vista insists it's a "better version".
Now I just use 3.1 and have no viruses!
|
|
|
|
|
Do not go too deep now
Clickey[▬]
»»» <small>Loading Signature</small> «««
· · · <small>Please Wait</small> · · ·
|
|
|
|
|
Corporal Agarn wrote: Or Microsoft. Don't let my Former Bitch Supervisor From HellTM hear you say that, she thought the sun rose, and set, on Redmond.
She believed program bugs were like roaches. If you saw one, there were at least ten, and no program was bug free.
However, one day we encountered a compiler bug. The machine code generated did not do what the source code said.
We showed her the two side by side, since she couldn't read assembler code, she insisted the problem was ours.
We reminded her that the compiler was a program and of her stated position on bugs.
Her response, it's a COMPILER, not a PROGRAM, and therefore exempt from her rule.
Besides, Microsoft does not issue products with bugs.
No. Exaggeration.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
Pawel Krakowiak wrote: I feel that whoever breaks stuff should be publicly shamed
We have a Trophy affectionately called the f***-up cup. If you discover a bug, you can award the cup to the person who implemented it and they have to display it on the highest part of there desk until somebody else is awarded it. It works really well as the person who finds the bug is usually happy to fix it as they had the pleasure of awarding the cup to the original culprit. Or sometimes you can have a quiet word with the culprit who 9 times out of 10 will drop whatever they are doing to fix their mistake in exchange for you not giving them the cup and thus drawing everyones attention to it.
|
|
|
|
|
P0mpey3 wrote: Or sometimes you can have a quiet word with the culprit who 9 times out of 10 will drop whatever they are doing to fix their mistake in exchange for you not giving them the cup and thus drawing everyones attention to it.
Now that's motivation!
Marc
|
|
|
|
|
I agree, this is a great approach.
YOU are responsible for YOUR CULTURE. I say you work with the Team, and do stuff like this.
Find cool ways to celebrate the process and "reward" the problem children. We had padded karate blocking sticks. We could opt for a public (among developers, all getting their licks in) beating (body shots only). It did not hurt, but boy was it fun. I took the first beating for SIMPLY NOT coming up with the idea sooner... That got everyone into the spirit.
Finally, where are the code reviews? People who break things often MUST have their code reviewed by their peers before publishing.
|
|
|
|
|
Trophies like this work great, just don't let management get their hands on it or the award process. Ideally, don't even let them know what its all about, so there's no chance they can use who's got it against them.
At my previous job, the other developer and I instituted a couple of different trophies for various mistakes. They were great fun for years, until management made a big deal out of awarding one of them to one of the developers in a big public display in front of some customers who had come to visit. We never awarded the trophies ever again -- they weren't fun anymore and management obviously took too much notice of who was getting them.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Do you really think the person who broke it, has the skill set to fix it?
Public shaming doesn't work and it is terrible for morale.
|
|
|
|
|
Slacker007 wrote: Public shaming doesn't work and it is terrible for morale.
I saw a plugin or something (years ago) for Continuous Integration servers which on a failed build adds the avatar of the dev who broke it and displays it on the page. I think it's part of the game, it's not real shaming, just an incentive to quickly fix what you broke. No one wants his mugshot to be posted next to a failed build.
|
|
|
|
|