Tag Info

Hot answers tagged

28

None - Now I know this is going to be a controversial statement, but old technologies and techniques should not be unlearned because you never know when someone might find some old code that you have to dust off and understand and if you don't remember the technologies and techniques that were in place, that code is going to be a mystery. Likewise, getting ...


22

Single-Threading. Get used to the fact that your program is no longer a "main" function that calls other functions; more likely, your code will be compiled to some classes that live in some framework, which might create some objects, and call some methods, in parallel threads whenever you expect it least. A global static variable is no longer just "ugly" ...


21

Declaring all variables at the top of files This may have been good practice in the days of primitive compilers, but is not required in modern programming environments. Nevertheless, a lot of programmers who have been around for a while seem to do this without thinking. My preference is to see variables declared as close as possible to their first use.


20

How to overengineer everything for future-proofness. I get the impression that heavy OO engineering for every conceivable change was the paradigm of the late '90s. Nowadays we realize that you can't plan for every conceviable change and every bit of futureproofing against changes you anticipate makes changes you don't anticipate that much harder. It only ...


16

Design by Database If you're producing a business application of significant complexity, and the first thing that you do is produce a big chunky database schema -- instead of focusing on business logic, domain design, or service level interactions -- then please take that finished schema, wad it up, and eat it. Because that is about as much worth as you ...


13

Unlearn the concept that well-written code is also well-commented. I don't have a problem with any technology or technique in use today enough to say that we should all unlearn it. But this habit of writing comments to document and explain our code is so deeply (and unjustifiably) embedded in our profession. My annual performance review questionnaire has ...


8

Language is not only a syntax. It's also huge set of libraries, standard and popular non-standard, it's a platform which targets this language - CLR/JVM/Win32/POSIX/etc. So when you migrate to another language (or another platform with same language), you should spent some months to learn new libraries, API, platform quirks, best practices and other things ...


8

Hungarian Notation There's nothing wrong with "m_" for member variables but "m_sztrfgpCompanyName" outside of C or arguably in C programming it's overkill. That's what IDE's and modern compilers are for. (And yes, I know of all the dangers of void*, see "arguably")


7

Programming isn't always about how quick you can get an application out of the door I often hear people claim the old chestnut of how much quicker apps were developed and released to customers 10-15 years ago, but unfortunately these people don't appreciate the kind of obligations we as programmers are now under, an app that was banged out of the door ...


7

I would like many engineers to break themselves of the habit of using XML for anything and everything. Perhaps it is just the clients for whom I have worked recently, but I consistently see poor old XML bent, twisted and perverted towards uses that do not suit it. Specifically, I detest the notion that making a system configurable means loading and ...


6

C++ as a better C It used to be that C++ was mostly a better C, but the language has evolved much past that. Fortunately, the people I'm working with also have, but not everybody has. The correct way to write programs in C++ is much different from in C.


6

Everything Following the vain of the previous answer, I believe all habits are bad and boxing. Falling into any sort of habit can be construed as a lack of creativity which will stifle your perception of new technology or options. Learn patterns, don't make them a habit. Identify ones that work well and then apply them to new requirements. Don't put ...


5

I have had customers demand VB.NET over C# because "C# developers are more expensive." I don't care whether my guys type semi colons at the end of the line or not and I don't adjust their pay based on it. You know that guy who says "I've been rich and I've been poor, and rich is better"? Well I've had customers who tell me what language to write their code ...


5

A few years ago I remember someone claiming that developers could now forget all about optimizations like common subexpression elimination in loops, because "compilers are so much better now". It seemed reasonable at the time, but in todays world of interpreters and DSLs, a lot of those techniques are life- (or at least job-)savers. I'm not really ready to ...


4

Unlearn your Bias I can't tell you how many times personal bias gets in the way of the correct solution. Sometimes, inadvertently, I am biased and make sub-optimal recommendations. Sometimes others are biased towards the existing paradigm no progress can be made. All that said, you need to also know when to stand your ground on your approach (of course ...


4

Off the top of my head: market knowledge: will you find enough people fluent in the technology? At what cost? scalability: will it still work when your system will be used in production, with volume of data/requests that can go much higher than anticipated? modularity: is this technology easy to replaced should the need to do so arises? or will you be ...


3

Short answer, I don't think you can. If the HR people have not been told by someone internally that candidates with some experience set are acceptable they won't care. If they're looking for C# developers and you have tons of Java experience they won't know they are similar, and won't care what you tell them.


3

choose the right tool for the job if the tool doesn't matter, consider client preferences vs development and maintenance costs and explain the trade-offs clearly; let it be a business decision if the tool does matter, insist on using the right tool Note: if the client does not trust you to choose the right tool, they don't trust you at all. Find better ...


3

I have a couple... Unlearn Database first design. As mentioned above. Unlearn BDUF - big design up front. Unlearn functional & design specs. Functional specs should go away. They're always outdated by the time something is relaesed and what is produced is almost ALWAYS wrong. Unlearn well-written code is well-commented. This is wrong, as many are ...


3

Cobol I had suffered from people using Cobol mentality in other paradigms. I had to write it once in my life somewhere and this question helped a lot. I am talking about writing Cobol in other environments. In the country of origin there was a word for it: "Cololeiros" which initially I thought was a form of dance... There is a nice story in "Code ...


2

I experienced this situation more than once in my career life. Once we had a very successful native application and we wanted to sell it to a customer and they demanded .Net because they have been told that it's the future. Other situations were very similar.Some customers ask for some kind of technology because they are influenced by marketing and ads.


2

Inventing the wheel Back in the day, there were no easily reusable objects or online services we could just plug into, so we had to write our own before we could start tackling the real problem at hand. It's hard always remembering to check whether someone else has solved a problem before setting out to do so, epecially when some part of your brain ...


1

If you implement the server as a bunch of web services then you don't really have to worry about syncing your model classes between the server and the UI. Every time you change something on the server it will impact your web services definitions (WSDL) and as a consequence will have to be remapped in your UI accordingly. Java has several tools that will ...


1

I'm sympathetic to your plight. I agree that some technologies are very easy to learn, and it's frustrating when an HR department doesn't understand that. To understand a bit better, you should understand the psychology and politics behind job descriptions. A job description, although occasionally well thought-out and well-written, is more often cobbled ...



Only top voted, non community-wiki answers of a minimum length are eligible