Elizabeth
Engineer
Engineer
  • UID625
  • Fans4
  • Follows1
  • Posts68
Reads:1911Replies:0

[Share]A small test on programmers: The conservative vs. the liberal

Created#
More Posted time:Jan 11, 2017 9:35 AM
Recently I am reading Steve Yegg’s A Programmer’s Rantings.
This is a very interesting book and it even contains a small test to tell whether a programmer is a conservative or a liberal.
There are a total of ten questions listed below and each question has A and B options. You should select your preferred answer.

Question 1: The bug hasn't been fixed yet. Can the software be launched online?
(A) Before launching software, you should write a complete test to fully debug the software and try to fix all the bugs.
(B) No matter how hard you work, you cannot eliminate bugs. If the bug is not serious in nature, you can launch the software first and debug and fix it based on feedback.

Question 2: Should error-prone features be used in the application?
(A) The advanced features of many languages are prone to errors and risks, and they should be disabled in the code. We can continue with the development without these features and code is therefore more secure.
(B) Smart programmers are self-driven to learn things and they know how to solve problems. Laying down a bundle of don'ts to avoid errors is totally undesirable.

Question 3: Should we set limits on new languages or syntax?
(A) The number of languages used in the company should be limited. So when the system goes down at midnight or on the Christmas Eve, the man on duty won't have to make a frantic last-minute effort to learn the new syntax. In addition, we should also disable the syntax that changes the original definition of the language, for example, imposing a strict limit on operator overloading and metaprogramming.
(B) The learning ability of programmers may surprise you and it is not necessary to “protect” them from learning new syntax. They will acquaint themselves with it as long as there is a need.

Question 4: Is static check necessary?
(A) Security checks of compilers are crucial. Code failing to enable static checks is usually unacceptable.
(B) Code should be short and concise, while static check tools may make the code unnecessarily lengthy.

Question 5: Is it a must to define the data format?
(A) Data must follow the pre-defined format. For example, relational databases must follow the TNF (third normal form) or UML; XML must have a DTD (Document Type Definition); and NoSQL databases must have a separate format definition (indicating all the allowed keys and corresponding value types).
(B) Stringent data definitions will only impede flexibility and delay the development process. A better strategy is to write some annotations, or define part of the data, or even skip the definition for the moment. Before a large number of user cases appear, nobody knows what the data may be like and “code first” is the proper course of action.

Question 6: Should the public interfaces be made static?
(A) Public interfaces must be strictly modeled. Data should never be untyped. All input and output entities must be fully and explicitly defined as models available for static checks.
(B) Public interfaces should be as simple as possible and both forward and backward compatible. Too meticulous modeling is nothing more than a careful guess of how the interface will evolve.

Question 7: Can we leave a backdoor for the convenience of modifications?
(A) Dangerous or risky backdoors are strictly prohibited in production systems. It should be impossible to connect to a working production system through debuggers, SSH, or any interfaces to modify the runtime code or data.
(B) The flexibility of the system sometimes has the final say about whether the customer or contract is yours or your competitor's. The potential safety hazards to the production system can be alleviated through logs, monitoring and auditing means. Facts prove that many large systems with backdoors of the highest permission and Shell interfaces have achieved sound risk control and flexible operation at the same time.

Question 8: Can we launch a much-needed system with potential safety hazards?
(A) If there are any concerns over the security of a component, the system cannot be launched at all events, no matter how hard the team implores.
(B) Enterprises should take risks consciously to stay competitive. Even if you don't want to take the risk, since the system is in urgent need of other systems, there may still be issues after it is launched. Such being the case, it's better just to chance it.

Question 9: Code runs slow. Is it necessary to solve the problem?
(A) Fast code running is better than slow running code. Nobody likes slow-running code so the code performance must be good. Performance awareness should be kept in mind from the very beginning to avoid using slow languages and libraries.
(B) Do not optimize the code too early. Run the code first. Correctness is more important than performance, and quick iteration of the prototype is more important than correctness. Optimize only when customers put performance at the top of the issue list.

Question 10: Which is your best recognized language?
(A) C++、Java、C#、D、Go、Clojure、Ada、Ocaml、Eiffel、Clojure、Erlang、Pascal、Haskell、SML.
(B) C、Objective-C、JavaScript、Visual Basic、Lua、Scheme、Python、Common Lisp、Smalltalk/Squeak、Perl、Ruby、PHP,Bash.

Conclusion
If more than half of your answers are A, you are a conservative programmer. You value software security and reliability very much and hate risks. You advocate strict management and hold that effective regulations are a guarantee of software quality.
If more than half of your answers are B, you are a liberal programmer. You value software development flexibility and call for more freedom for programmers. You are ready to accept a certain degree of risks and defects as long as new features can be launched online smoothly.
Being a conservative or a liberal is not a problem. Both are advisable. The problem is that a team is at its best when working as a single faction to stay harmonious, either all conservatives or all liberals, to avoid the rise of constant conceptual conflicts.
Guest