I remember a team-building exercise (not specific to programming, but it applies) where we told everyone to write out complete instructions on how to make a peanut butter and jelly sandwhich. After giving everyone some time, the presenter would then collect and "follow" the instructions as written without adding "assumed" steps or details. Frequently, this would involve getting to a certain point and not being able to complete it or with humerous results (you have to be willing to get messy). For example: --Take 2 piece of bread. (If did not specify opening the bag, it was ripped open. If they did not specify putting it on the table or plate, parts would be dropped.) --Put peanut butter or jelly on one piece of bread. (Could put the entire jar onto the piece of bread. If they did not say to open the jar, the presenter could tap on jar but not be able to continue. If they did not specify spreading with a knife, it would be done using fingers. Can optionally spread it on both sides of the same slice if they did not specify just one side.) --Put both pieces of bread together. (Could put with messy sides out or bread slices offset by 45 degrees.)
ewshaffer
Posts
-
Introductions to programming suck -
Browser Issues with WebsitesAll you need is to visit the wrong site once.... <head> <meta name="designedfor" content="my_custom_malware_downloader" /> <meta name="designedforversion" content="2.0" /> </head>
-
Code reviewsI worked for over 8 years at a company that had a formal code review process that was essentially integrated into the development life cycle (they worked on contracts requiring quality standards like CMMI and such). It worked very well there as it was a REQUIRED part of the process where a separate Quality Assurance engineer who understood code well enough to read it but did not actually write it and thus had no ego invested. The developer would put together a review package which was sent to other team members, the team lead, the QA engineer, and (when we could get one) someone outside the team (thus, they had no ego invested in that code either). We had a management-approved coding standard and they also agreed to having code review time (and unit testing) built into the schedule. QA also had the authority (though they never needed to exercise it) to prevent the entire contract from advancing to the next stage because they were required to sign off on it. If the QA mentioned that they were concerned about someone who resisted the process, you can be sure that management would get on the develper's case and they would either adjust their attitude, get reassigned, or start looking for another job. Similary, we would try to enforce constructive reviews and focused on looking for functional (not style) problems or made suggestions about alternatives (XX wrote a utility class which would simplify that, ...). If someone became nasty or non-constructive, they would get a visit from management. This worked because of complete management backing and the fact that developers were not allowed to short change reviews and testing due to the schedule (maybe because the customer originating the contract had to accept it with a formal test procedure approved by separate test engineers and QA as well, and it was also not tied to things like marketing and release dates). I've also been working for another large company that does not do them, but has occasionally expressed interest in it. I think that it will not really get anywhere until management really throws support behind it as it needs to become more of a "cultural" part of the process with time allocated towards the process. QA here is also more involved with testing in multiple environments and trying to find problems, but they never look at code (and I doubt most if any of them would really be able to understand it well enough to even "read" it)
-
US Job questionMost companies that I've seen have 9 or 10 holidays which are designated by the company (e.g. Christmas Day, New Year's Day, Memorial Day, Independence Day, Thanksgiving, ...) and some have 1-2 "floating holidays" which are essentially free days off that you have to use within the year (to cover themselves for non-majority religious holidays). In addition to (i.e. separate from) the holidays, they offer vacation (or "paid time off") days which vary from 2-3 weeks, though most increase that over time up to around 4 weeks if you stay with the company a long time. You should also clarify how they manage their "sick days". My current employer groups all time off from one pool (both sick and vacation). Another employer used separate pools for sick and vacation time. And another offered only 2 weeks vacation (for the first couple of years), but they offered "unlimited" sick days (though you are expected to only use them when actually sick and they might question it if you used more than the average).
-
A career questionHaving the bach. degree will help get interviews and the initial job experience. Larger companies are more likely to "require" a degree than a smaller company as part of the qualifications (though some allow experience to count, they also tend to pay a lot more to someone with the piece of paper). On the other hand, most larger companies will also help you obtain a master's degree by reimbursing you for your tuition, .... One of my former employers (larger company) also liked to see employees learning new things either through training or attending classes (which led to higher ratings and thus, pay increases). Overall, I would suggest getting a job before the master's degree and see if they are willing to help by paying you to get the master's degree. As for the Phd, I would only consider that if the career you decide to follow somehow (e.g. some upper echelons of government work, research and development companies, ...) rewards or requires it... or if you discover that you just like the academic challenge without much return on investment. Most companies do not care one way or the other if you have one and it does not really help, though if you still want one, try to get them to pay for it.