Monday, June 9, 2008
Lies We Tell New Programmers
Here parents' desires conflict. Older societies told kids they had bad judgement, but modern parents want their children to be confident. This may well be a better plan than the old one of putting them in their place, but it has the side effect that after having implicitly lied to kids about how good their judgement is, we then have to lie again about all the things they might get into trouble with if they believed us.
If parents told their kids the truth about sex and drugs, it would be: the reason you should avoid these things is that you have lousy judgement. People with twice your experience still get burned by them. But this may be one of those cases where the truth wouldn't be convincing, because one of the symptoms of bad judgement is believing you have good judgement. When you're too weak to lift something, you can tell, but when you're making a decision impetuously, you're all the more sure of it.
Like our kids, we want our new programmers to be confident but afraid that they make lousy judgement. Another good point:
One thing adults conceal about sex they also conceal about drugs: that it can cause great pleasure. That's what makes sex and drugs so dangerous. The desire for them can cloud one's judgement—which is especially frightening when the judgement being clouded is the already wretched judgement of a teenage kid.
Writing lousy programs is great pleasure like sex or drug because it uses less time, less effort to meet your customers and bosses needs. I highly recommend all technical people to read the Paul Graham essay.
chris tam
Hong Kong
Friday, June 6, 2008
The Cost of Working for Government
Is this your dreaming IT career?- The head of IT has been in government for 27+ years. She is the one making purchasing decisions and setting strategic direction. She does not own a computer or have an external email address. She does not buy on-line, and she has the web monitor set so tight you can forget about using the Internet. No IM. No webmail. Then to ensure you cannot possibly reach the outside, no non-government equipment permitted in the building without a specific exception. This will be your organizational leader as the rule - not the exception.
- Change is glacial. Two weeks I did nothing because they could not allocate a machine for me to access the network, until I had a badge. To get the machine, a form needed to be signed by my boss, his boss, her boss, and his boss. My boss walked it around, and was told that was inappropriate, and it still took 4 hours. Then it went to the help desk who took 9 business days to process and deliver the equipment. Deliver in this case meant coming to my desk and providing a user id and password to a machine sitting there. To install software requires you to have an exception form filed. Another round of 4 signatures in my department, one from security, one from the helpdesk and one from a person who no one can explain except they need to sign the exception form - six days. Complain or bother anyone about a request and it will disappear. Petty is an understatement.
- It is true that no one gets fired. But worse, making decisions is career limiting. The solution is to ensure you never do anything of risk. What you want is to be tied into a project you can claim some responsibility with, if it goes well, and disavow any relationship if it fails.
- No _one_ makes any decisions because there is safety in numbers - very large numbers. All decisions are by committee and expect it to take weeks. They spent 12 weeks, with a minimum of six people in nearly 20 meetings discussing a database key. One key. It is an extreme example but that it can happen says it all.
- If you take any type of leadership position and do anything that employees do not like - they submit a grievance. Why? Because while one is pending, they cannot do anything to you, include request work, or deny automatic or scheduled promotions in grade. A 25 year developer? here has had a grievance on her various leaders, continuously for over 12 years. She is proud of it. "They don't tell me what to do!"
- Write off leaving government. You can always leave right? Wrong. Would you hire someone from an environment that fosters the behavior above? With very few exceptions, spend more than a year or two as a "gov-e" and you can kiss the private sector good bye. Who would want this behavior and if it took you more than a year to figure out you should quit, that says volumes.Unless you want to do what you are being hired to do for the next 20 years, with 2.5% annual increases in pay, bosses who make no decisions and run the same technology for decades - run away.
chris tam
Hong Kong
Wednesday, September 26, 2007
STOP thinking programmer
Chris tam
Hong Kong
Tuesday, August 14, 2007
Do Programmers have Make-Work, Anti-Foreign and Pessimistic Bias?
Anti-Foreign bias means that oversea programmers is often lower skill and unable to write good quality program. Also Anti-Foreign bias can also means that VB programmers argue that Java is too complex and too difficult and too ineffective for development. Or the C++ programmer argue that Java is only a downgrade of C++. Or the Java programmer argue that Ruby on Rail is not suitable for enterprise application. My note is: Most are myths but some are true. [My own Anti-Foreign bias is against Java Annotation, but not Bob Lee's google giuce (some features are really better than my lovely Spring) or Graeme Rocher grails (I learn too much groovy that I can't miss how they are used in grails). The current Java Annotation implementation is too bad. In my current programs, I have already mixed too many unrelated Annotations in a single file that it look more like a messy sh-t.]
Pessimistic Bias means that programmers are always afraid that the IT world is ruled by Microsoft and all programmers become microserf. (My note: Microsoft will never rule the IT world becase it does not have the gun to collective microserf tax.) The java programmers are afraid that there are too many framework(strut, spring, webwork, etc... (believe me, the list has more than 1000 item) and the java language will not be ONLY holy programming chosen by GOD of programmer (Not Gosling, he is FATHER of JAVA) and java will be contaminated by Ruby or other scripting language. My Note is: Do a lion afraid that he/she will be eaten by you? No. Only those who do not run will be eaten by Lion of the Future.
In Bryan Caplan's book, "Myth of Rational Voter", if you have all these biases, you are a normal voter. You are qualified to elect US president. The above information is not a joke but a serious question. You can add more your favorite bias to them.
chris tam
Hong Kong
Sunday, August 12, 2007
Correct Incentive Mix For Programmer
- A reasonable salary and/or bonus. There are too many employers that think the sentence "Good job. Well done" is equals to salary.
- Meeting is always required by managers that want to show their contribution and involvement in the project. Also meeting is the only way for the managers to understand what have happened in the project. But none of them are incentive to programmer. The best way to provide incentive to programmer is to limit the number and time of all meeting.
- All human are social animal, including all programmer. No matter how poor a programmer communication skill is, he still need other programmers. An environment that help the programmers socialize easily is a really great incentive.
- All programmer need to have a sense of control on the programmer. A "sense of control" is always within the programmer inner economists. Don't let the "DEVELOPMENT METHODOLOGY" banner overrides all the programmer sense of control.
chris tam
Hong kong
Sunday, August 5, 2007
How to make Guice and EJB and SEAM bloat and ugly
...
@Inject
@Transactional
@Stateless
@Column(name="foo",type="VARCHAR"...
@Criteria(type="manager"...
@DynamicInclude("Bonus")
@MyJTextField(size="12",...
@Validate(require=true...
@MyFormatter(format="...
....
public void setFoo(MyObject foo) {
...
What is the problem of the above code? All the Java Annotations are NOT modularized and the Java Annotations BLOAT. I think Java programmer must think carefully about this. Otherwise Guice will bloat, EJB will bloat and JBoss SEAM will bloat.
chris tam
hong kong
Sunday, July 22, 2007
Strange behavior when wiring Groovy beans in Spring without Java Interface
package test ;
public class GroovyBean1 {
def groovyBean2 ;
}
And GroovyBean2 is defined as follow:
package test ;
public class GroovyBean2 {
}
In the spring xml config file, you can wire them as:
...
<lang:groovy id="groovyBean1" source="classpath:test/GroovyBean1.groovy">
<lang:property name="groovyBean2" ref="groovyBean2"/>
</lang:groovy>
<lang:groovy id="groovyBean2" source="classpath:test/GroovyBean2.groovy"/>
...
If you load the above spring xml config file with ClassPathXmlApplicationContext, you will find that "GroovyBean2" is successfully injected into "GroovyBean1". But if you change GroovyBean1 source code as follow:
package test ;
public class GroovyBean1 {
GroovyBean2 groovyBean2 ; // <-- change untype variable to "GROOVY" type variable
}
ClassPathXmlApplicationContext will throw an Exception when it tries to inject "GroovyBean2" into "GroovyBean1". Why does Spring IOC not work with "pure" groovy objects that does not implements any Java interface? The problem is due to Groovy class loader. The "GroovyBean2" definition in GroovyBean1 and the "GroovyBean2" definition in Spring xml file belong to different class loader so the Spring IOC throws Exception. Is it possible to solve this problem by using a single GroovyClassLoader to load both GroovyBean1 and GroovyBean2 objects. The answer is simply "NO"!!! Because GroovyClassLoader always create a new InnerLoader when compile a groovy script file. If anyone has a solution, please leave a comment.
chris tam
Hong Kong