Suggestions not to make when starting a new programming job

When starting a new programming job, it can be risky to suggest certain things. Others at the company do not know you well enough, and saying the wrong thing will immediately create a bad first impression, branding you as too inexperienced for your role or not a team player. Make one of the following suggestions, and your new job may not even last you a week.

Let's rewrite the codebase for the application in another language.

If you weren't hired as a design consultant or to re-engineer the big-picture, suggesting to rewrite a key application in another language is almost certainly going to get you fired close to immediately.

There can be many good reasons why an existing code base is in a particular language:

• It's a language all the other developers at the company already know.
• It's the only language certain key libraries exist in.
• The language for whatever reason excels at what is being accomplished with it.

In any of these situations, your suggestion is saying to switch to something the existing talent is unfamiliar with, or an admission of not understanding the scope of what is being done. In the former, you've just admitted to not being a team player, in the latter, you've admitted to having too little experience. Further, such a suggestion will indicate you probably are not as experienced with the language as your resume or initial interview seemed to convey, and perhaps you're a liar as well.

Additionally, even if none of the above reasons are valid for the case at hand, no manager wants to delay a project to rewrite everything. Furthermore, rewrites are nearly every manager's nightmare, as they fear new bugs being introduced. All this combined, expect little job security when making such a suggestion early on.

If you're tasked from the get go with fixing some small script, you can probably get away with changing the language - if you get approval first. But ask about it in a way where it is clear you are concerned what is best for maintaining it by others in the future, not as what is easiest for you and shows indifference to the company's needs.

This applies to any sizable rewrite in general. Few will care about rewriting some small script or component. But offering up front when no one knows you to rewrite a large project, even in the same language, is just asking for trouble. Sizable rewrites normally aren't done unless there's a team in place that are already known to be able to work together, and can do so reasonably quickly and with relatively few bugs in the process.

Let's switch to another version control system.

You may find yourself on your first day having to use a version control system you are unfamiliar with. Do not blurt out that you'd prefer an alternate system. Doing so is tantamount to demanding the rest of the company cater to your familiarity or preferences, instead of you trying to conform with the rest of the company.

Existing version control systems may also be entrenched into much of the existing infrastructure and work-flows. There can be many scripts in place that were written long ago and only work with the particular version control system in use. The entire business may even depend on these scripts for managing all deployments or builds. If so, you just asked to flush the entire company down the drain.

I've had the recent displeasure of hiring a short-lived employee who demanded and fought for us to switch to Github from his second day at work, before even learning about what our needs were and if Github was or wasn't a good fit. Github may be terrific for working with Git for an open source project, but it's not necessarily a good fit for proprietary projects. Github for private repositories costs money, and even if it were free, you don't necessarily want to share your code with a third party when you are quite capable of locally hosting Git repositories and tools. It was pretty clear from this employee's passionate backing of Github that he had little idea of what our source code hosting objectives were, too inexperienced to realize there are considerations other than the features Github offers, and his passion revealed he wasn't going to be a team player. He was let go fairly quickly.

Let's move everything to another hosting provider such as Amazon Web Services.

Amazon's web services provide a continuously growing offering of all kinds of web services to run your business. It is getting quite popular due to being a one-stop-shop for many kinds of businesses, and offering very low prices for various use-cases. Amazon also provides elaborate APIs for developers to make use of in order to manage their services and maintain interesting software. Similar kinds of hosting services are showing up from Microsoft, Google, and others as well.

Some developers who have experience with these services want everything hosted there due to their existing experience or ease they know they can get certain tasks accomplished with them. But that doesn't mean these services are necessarily right for a business.

These services, such as AWS, bill according to every kind of individual usage they can meter. Their costs are very low and highly competitive for minimal usage. However, once you get into large amounts of usage, competing services from smaller companies which offer flat rates may be more cost effective. Some business will also choose a flat rate service over AWS and those like them, because with those metered services, pricing is unpredictable. One doesn't necessarily know up front how much usage will be occurring, and that can make it difficult to work out a budget or be profitable with certain pricing models for applications built upon these services. These businesses will choose a flat rate model even if AWS or others like them are cheaper, simply because there are no surprises later.

Whatever existing service is in use may also be entrenched for a variety of reasons. So before making a suggestion which may show you have zero business sense, or disregard for how things are currently running, get an understanding of what is presently being used and what the pros and cons of a switch are. There can be very good reasons why some hosting company's service is not already in use by the company before you arrived at your new job.

Let's switch the servers to a different Operating System, Application Server, or Database System.

For many of the same reasons described by previous statements, such a suggestion is revealing inexperience, incompetence, or a demand for everyone else to revolve around you. Various OSs, servers, or DB systems are better geared towards working in certain areas. Demanding a change will make people think you don't understand why something is being used. Even if you are correct that something else is better, the existing system is probably entrenched, or the existing talent can't work with anything else. Such demands only show you have little business sense, or can't be a team player. Unless you're specifically asked for an opinion in these matters, don't offer one!

Conclusion

Nobody likes change. Change is hard. Change may even be a very bad idea. Change can fail. Others may be unable to adapt to change.

Before suggesting changes like those above or similar things, really understand why something is being used, and what others are able to deal with. If you can't work out the pros and cons or understand what the impact of a change is going to be, nobody wants your opinion. If you're a new and lowly employee on the corporate ladder, it is best to keep your mouth shut.

If you feel strongly a change is needed, this is usually an indication you are inexperienced or cannot be a team player. Experienced programmers will find a way to do almost anything with anything, they aren't locked into a single tool to solve a problem. If you've been somewhere a while, and your colleagues respect you, then approach these things very carefully. Ensure your proposal is in the spirit of being a team player and in the company's best interest. Otherwise, prepare for a pink slip.

If you're a manager, it may be useful to note that all these above kinds of statements, if made early on, are symptomatic of programmers who are incompetent. Probably best to fire them immediately and not waste resources on them that can be better spent training their replacement.

A stronger C/C++ Preprocessor

Ever felt you needed some preprocessing to generate some C/C++ code for you, but the C preprocesssor is too lacking? Say for example you wanted to include part of another file, or include output from an application. Perhaps the compile should be based on some data found on a remote server? Well, there are stronger preprocessors which work for C/C++, such as PHP.

Here's an example:

/tmp> php test.cpp.php | g++ -x c++ -Wall -o test -
/tmp> ./test
Hello 0
Hello 1
Hello 2
Hello 3
Hello 4
/tmp> cat test.cpp.php
#include <iostream>
int main()
{
  <?php for ($i = 0; $i < 5; ++$i) { echo 'std::cout << "Hello ', $i, '" << std::endl;'; } ?>
  return(0);
}
/tmp>

Here's a more interesting example:

/tmp> php weather_example.c.php | gcc -x c -Wall -o weather_example -
/tmp> ./weather_example
Hi, when I was compiled, the weather here in New York City was 57F
/tmp> cat weather_example.c.php
<?php
$w = file_get_contents('http://www.google.com/ig/api?weather=New+York+City');
$f = '<temp_f data="';
echo '#define __WEATHER__ ', (int)substr($w, strpos($w, $f)+strlen($f)), 'U', "\n";
?>
#include <stdio.h>
int main()
{
  printf("Hi, when I was compiled, the weather here in New York City was %uF\n", __WEATHER__);
  return(0);
}
/tmp>

Ancient coding ideas finally in English - Part 2

1. 
   What is the best way to write it? Whatever is best for the program itself and best for the programmers.
   Be just as careful with with minor code as with major code, as you don't know in the end which will be more important.
   Consider what you lose when not writing the code properly against its gains, and consider the benefits of a poor implementation against what it loses.
   Focus on three things and you will avoid code repetition: Know what other code exists, others will review your code, the code will exist for a long time.
   


2. 
   It's best to write code for the customer's demands, they will overlook its negative qualities.
   Code that's not written for those buying it will be for naught, and improving it will lead to code repetition.
   Those writing for a community should write the code for its own sake, those that came before you will help you.
   You will end up getting credit for the work that gets added on as if you yourself did it.
   


3. 
   Be wary of standards bodies or other organizations, since they only recruit people for their own agenda.
   They will act like they love you when it is to their advantage, but they will not stand by you when you need it.
   


4. 
   Desire what the community wants, and the community will want what you desire.
   Do what they want instead of what you want, and other programmers will desire what you desire.
   


5. 
   Don't alienate the community.
   Don't trust code till the code is about to be recycled.
   Don't judge an implementation till you try to implement it yourself.
   Don't do something that is unaccepted hoping it will eventually be accepted.
   Don't plan to only write it properly later, maybe you won't.
   


6. 
   An idiot doesn't care about code repetition.
   One who is unlearned will never be a hero.
   One who is embarrassed will never learn.
   One who is always angry and demanding can't teach.
   Those who solely focus on making money will never be more than an idiot.
   Wherever there is no one else to write the code, you write it.
   


7. 
   The master who invented the above statement once looked at a hack being recycled, and stated:
   Since this hack replaced an older hack, it itself got replaced, and the hack replacing it will also be replaced.
   


8. 
   One who increases code size increases bugs.
   One who increases features increases worry.
   One who increases threads increases overhead.
   One who increases processes increases communication layers.
   One who increases the amount of code they solely enjoy increases black magic in the code.
   One who increases usefulness of the code increases its lifespan.
   One who increases the amount of thought put into writing the code increases its intelligence.
   One who increases his own agenda only does so for himself.
   One who increases usefulness for the sake of the community will earn for himself everlasting gratitude.
   


9. 
   If you write a lot of code, don't view yourself as so special, because it is for this reason you became a programmer.
   


10. 
    The master who invented the above statement had five students.
    The first was someone who never overlooked a detail.
    The second always looked to the source of the issue.
    The third was a hero.
    The fourth always avoided code repetition.
    The fifth was always increasing his own understanding and knowledge of techniques.
    


11. 
    The master said of his first student, if we weighed him against everyone else out there, his abilities would outweigh them all.
    Another master said, if the fifth student was weighed against the other four, his abilities would outweigh them all.
    


12. 
    The master asked his students: What is the best trait for becoming a good programmer?
    The first answered: One who carefully checks his code.
    The second answered: One who has a good friend to bounce ideas off of.
    The third answered: One who sees the needs of those around him.
    The fourth answered: One who anticipates future needs.
    The fifth answered: One who desires to write the best code he can.
    The master stated, the fifth answered best, as his answer includes all the others.
    
    The master then asked his students: What should a good programmer avoid?
    The first answered: Ignoring what is going on in the code.
    The second answered: Idiot friends.
    The third answered: A weak community.
    The fourth answered: Allocating resources without freeing them.
    The fifth answered: Becoming complacent in his understanding of what is best.
    The master stated, the fifth answered best, as one who becomes complacent will end up with what everyone else answered.
    


13. 
    Stick up for your fellow programmers as you would for yourself.
    Don't get angry easily.
    Fix the code before the problem is apparent.
    Enjoy the fire of clever code, but be careful lest you be burned by it.
    


14. 
    Bad analyzing, no desire for good code, and hating your community will all cause one's code to be thrown away.
    


15. 
    Managing resources you allocate should be as important to you as managing the resources you already have.
    Perfect your programming abilities, as this is what a programmer is.
    All your code should be written for its own sake.
    


16. 
    Be meticulous in learning about what you need to accomplish, and the tools necessary to do so.
    Don't make the theory of prime importance.
    Don't underestimate yourself, and don't think your work will only be minor.
    


17. 
    Have a good answer ready for those who may find issues with your code.
    Understand your customer.
    Understand your employer.
    


18. 
    The day may be short, but there's a lot of work to be done.
    Programmers are lazy, even though their programs do much.
    The boss is demanding.
    


19. 
    You don't have to do all the work by yourself, you don't have to finish every last bit of it.
    You however can't leave the code in disarray.
    If you write a lot of good code, you'll be properly compensated for it.
    Believe that those who employ you will compensate you for your effort.
    Know that those who put in the effort will be compensated greatly in years to come, even if not initially.
    

Ancient coding ideas finally in English - Part 1

1. 
   Each great programmer learned programming from the master before him.
   Be precise in writing code.
   Teach programming to others, as you'll understand how things work better yourself when you're forced to explain it.
   Put safety in your code, don't just look at what minimally works, protect yourself from careless mistakes.
   


2. 
   Good programs depend on 3 things:
   The code.
   The hardware.
   The presentation.
   


3. 
   Don't write a program to get bare minimum done, and be over with it.
   Rather do it for the sake of the program itself, and try to get the most out of the program.
   


4. 
   Your code should be welcome to other good programmers.
   You should pay attention to minor details of their code.
   Pay attention to their ideas.
   


5. 
   Your code should be open for improvements.
   Let even simple programmers review it for mistakes.
   Be minimalistic on communication layers in your code.
   [The previous] refers to communicating with your own code, this applies even more so when your code has to communicate across a network or other external dependencies.
   Excessive external dependencies or communication across a network only hurts your program, and worsens code quality, and you'll end up with an unmanageable program.
   


6. 
   Declare over yourself a coding standard.
   Buy yourself friends to bounce ideas off of.
   Accept every new idea for consideration, no matter how ridiculous it might seem at first glance.
   


7. 
   Stay away from bad libraries.
   Don't statically link to them.
   Don't give up when it's a disaster out there.
   


8. 
   Don't make yourself a sole reviewer of large amounts of code.
   When presented with two implementations, assume both of them are complete garbage until convinced otherwise.
   When having to decide between two implementations you are presented with, examine the pros and cons of the situation, and what improvements can be done, and be happy when proponents of each were able to walk away being able to accept the pros and cons and reach the best implementation.
   


9. 
   Review code in depth, and have ever changing methods to do so, otherwise a severe bug can slip by you.
   


10. 
    Love writing code.
    Hate bureaucracy.
    Don't give in to status quo.
    


11. 
    Be careful in what you to say to others, or you may create a rift in your community, the outcome of the current work will fail, and your program will be for naught.
    


12. 
    Love peace and run after it.
    Love the other programmers, and show them how to write better code.
    One who only seeks to advance his own self will end up destroying himself.
    One who doesn't learn what's new will end up not being able to write code with what he currently knows.
    One who doesn't learn at all shouldn't be writing code.
    One who doesn't use libraries the way they're supposed to be used will be lost in the end.
    


13. 
    If you don't write the code, who is going to write it for you?
    If you're always writing all the libraries yourself, what's the point?
    If you don't write it today, then when exactly?
    


14. 
    Take programming seriously.
    Optimize the little bits which do the most.
    Welcome all patches with a smile (even if you don't commit them all).
    


15. 
    Make for yourself a system, and stay away from assumptions, learn about it if you're not sure.
    Don't write a program based on rough estimates.
    


16. 
    I've spent a lot of time with those who know only theory. Don't argue with them, just pay attention.
    The theory isn't the main thing, but the practical. If you dwell on the theory, you'll end up being repetitious with your code.
    


17. 
    On three things a good program depends on:
    Meeting Requirements.
    Correctness.
    Peace with the community.