I believe, I program good, at least my code produces results...
But I feel I have drawback... I hardly follow any naming conventions... neither for variables.. nor for methods... nor for classes... nor for tables, columns, SPs... Further to this, I hardly comment anything while programming...
I always think that, Let me first see the results and then I will come and correct the var names and other things later... (Thanks to visual studio's reflection here)... But the later does not come...
So, I need tips, to force myself to adopt to the practice of following naming conventions, and commenting...
Edit : I totally understand the ill effects of my practice, and I also know, that it is bad... My question is how do I force myself to follow the discipline...
Are you able to ask others for code reviews? Or even try pair programming? Both of those can really help you to do things you know you really should do.
Also, depending on your language/platform, there may well be lint-like tools you can run to check your code's health.
I hope you get to spend a few years working on code produced by someone else that has the same poor coding practices that you have. Only then will you truly understand how poor your code really is. Code that "works" is the bare minimum, writing code so that it is easy to to support, extend and maintain is where the genius of a good programmer is.
My gut tells me that your code is probably not as good as you think if you have no standards. You really just have to pick something, and stick to it. Being haphazard in coding style probably means you are haphazard in logic, which probably means you have a lot of bugs, and unexpected results in your code that will be hard to deduce later. Good luck.
Just remember the general coding guidelines you need to follow. And as you write the code write as per the guidelines with proper variable naming conventions for variables and methods and have function headers. Dont think whether your code will work or not, and code as per the guidelines.
Comments can be added later, but the naming conventions has to be followed even while doing a proof of concept.
Write your code with a confidence that its going to work.
Have your code reviewed by your peers, and also you can use Fxcop for static code findings.
Best of all, your code should work and should do what it's supposed to. It's what you get paid for.
However, if it is not readable, then it will fade into existence, because in time you will not remember what it does. To avoid this, refactor and document your code as soon as it works. As a rule of thumb, you should not be satisfied with your work before it is documented properly. For each method you write, this should not take too much time. But the longer you wait, the more time it will consume to figure out what your code was supposed to be doing.
I know the best way of all is to document before writing, but that won't work with cowboy coders. The other way around might be a good alternative, because readable and good documented code shows off a developer's skills.
This is a matter of coding discipline. If you want to prototype something and then throw the code away, this is acceptable. However, the instant you need to reuse or debug your code, you will regret having no comments and poor method/variable name choices.
While you are working with the code now, you know what it is doing. In a few months to a year, you will not remember everything so clearly. Then, you will likely regret not commenting your code and not choosing good names.
Consider, too, if someone else were to read your code, how easy would it be to understand?
Running something like StyleCop (if you're writing C#) can go some way towards this. It won't warn you about everything, but you can use it to make sure your methods have documentation comments etc.
However, as others have said coding discipline is something that has to come from within, not without.
If you want to change something about yourself, you need to motivate yourself to change it. That's one of the "rules of life."
This isn't really something Stack Overflow can help you with. I suppose that a good suggestion to build up some motivation is finding yourself a job as a developer and see how far your development habits lead you...
-Carlos Nunez
Related
When I write html and css, does it matter if I do things "my way", like using an abundance of absolute positioning, or maybe coming up with very unorthodox solutions to certain problems like layout? Since I'm not great right at markup right now, I am kind of just "doing what works." I'm reading as much as I can but I know I am making mistakes. Is it important that I pay extra special attention to exactly how I'm writing it so I don't develop bad habits, or should I just be happy that it validates and that is the most important thing?
It has to do more than validate. It has to look good, or at least be functional. The only way to truly validate that is via extensive testing.
It's worth noting that the standard patterns are there for a reason—because they work. But they're certainly not gospel. Metaphorically speaking, there's more than one way to skin a cat. There's no reason for too much hand-wringing if you find alternative solutions that work for you. The only real concern is that your code might be more difficult to understand and/or maintain in the future, either by you or by someone else.
Above all, though, the best way to learn and improve is to practice. And there's no better way to practice and discover your mistakes by writing and shipping actual code. If you make a mistake, chalk it up to experience. That's what we all do.
I'd say it's somewhere in the middle. It's important to always ask yourself "is this the best way to write this", but it's equally important to not get too hung up worrying about the perfect way to do things and just ship code. The more experience you get by getting stuff out there on the web in people's hands, the better position you'll be in to know what "the best way to do things" is.
It will all start to matter once other user has to maintain your code.
You should watch these videos. http://code.google.com/edu/submissions/html-css-javascript/
"should I just be happy that it validates" I would say never. If your code is working well doesn't mean that it is setting upto the mark.And the best way of knowing you have done correct coding or not is check your HTML pages in all the available browsers/in different OS with different screen resolutions etc. You may like to see what are the standards defined (however may vary depending upon your application needs) for CSS and HTML. So try to learn those things instead of doing it in "your way". Here is one reference for you.
Standards HTML/CSS
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
For design websites is it better to do it your self by learning HTML/CSS or using web design programs? and why?
I've bounced back and forth between hand coding and Dreamweaver in my history as a web developer.
I originally started out hand coding HTML. This was back in the day when table layout was king, and editing nested tables became a real headache. Couple this with a lack of good tools for visualizing hidden elements and this quickly became a nightmare.
I started using Dreamweaver primarily to speed up my table design workflow. Soon, however, Dreamweaver's templating system became a godsent when I started producing static websites that had no server backend. Being able to update one template and have it propagate across the entire static site cut down my cross-page inconsistencies to nearly zero.
More recently, the whole web 2.0 push has got me, and almost everyone else, back into the hand coding game. I found Dreamweaver wasn't really suitable for the compliant designs, since it was heavily table-centric. I find that most of the HTML I write these days is so straightforward and simple there's little need for an editor. Additionally, all my development is now dynamic once again, so there's no need for a static html generating template system anymore.
Learn for yourself so you can figure out how to do things exactly how you want them to be done, and not have to rely on some sort of program to figure it out for you.
Like anything else in technology, learn the core concepts first, and then use a tool to automate the things you have mastered. By doing so, you will gain a better understanding of how everything works together, and you be able to easily tell when something goes wrong. In this way you will not be bound to any one design tool, and can use whatever works best because you understand the core concepts.
In the words of Richard Feynman,
"That which I cannot create, I do not
understand."
They really serve two purposes, and either one is "better" for it's purpose.
If you learn to do it by hand, you will:
Have more control over exactly what is happening
Have less extraneous code
Be able to maintain your code more easily
If you use a program, you will:
Be able to design visually
Possibly be able to design more quickly
Not have to learn to write CSS by hand
It really depends on what your goal is.
I prefer HTML/CSS by hand because you have the most control over the code. Most design programs will add additional markup that is not required. Even simple WYSIWYG JavaScript editors add extra markup. Although, not a huge difference in file size, the additional markup will add up over time. I would also argue that its easier to maintain code when you know what went into its creation.
Additionally, you'll learn a lot more by taking the time to do it by hand.
Personally, I always edit my HTML/CSS by hand using editors with auto-completion if I can, because that always makes life easier. You should definitely always learn a language as much as you can before you start relying on any program to generate code for you, because most of the time you end up fixing what they gave you.
I tend to do it all by hand.
Doesn't matter what IDE or
server-side language I'm using.
Mark up is markup. Being able to do
it rapidly by hand is valuable.
More often then not, you'll have to
edit some markup manually. By
writing it from scratch, you're
already very familiar with the structure of the markup.
You don't have to spend any time
orienting yourself to the
designer-generated markup.
Although not necessarily a rule,
those who live in the designer I've
found to be less sharp in their
markup and code craftsmanship.
I prefer the by hand approach. That way you know exactly what you're getting. Plus I haven't found an editor that produces HTML/CSS that doesn't need some tweaking especially if you are targeting multiple browsers.
Doing it by hand. Using design programs tends to insert a lot of extra markup you don't really need, which will just complicate your ability to learn.
If you do it by hand you at least know what was inserted where, and why. Plus there are a lot of good websites out there that can walk you through the basics.
IMO you will still learn using web design programs like Dreamweaver, since you have to look at the source and make it fit your exact desires,and its quicker. But doing it by hand will give you the more you write the more you learn type of thing that I agree with 100%
This is a bit vague.
I think that "better" (qualitatively) depends greatly on (1) the competency of the designer, and (2) the sophistication of the application.
Regarding "better" (as in "advisable"): using an application can be a crutch that may fail to save you in all cases. Knowing how to "raw code" html and css is valuable in understanding the limitations of the application and working around those limitations. For that reason alone I suggest knowing how to do it by hand and then keep a sharp eye on the output generated by the application, should you choose to use one.
The absolute best is when you understand what you are doing - you can only do this by coding by hand.
If you don't know HTML or CSS and you use a WYSIWYG editor then how can you be sure everything is right? You can't!
If you have a good understanding of HTML and CSS why would you use a WYSIWYG editor? They make things harder because you can't see the code and extra tags and rules get inserted without you knowing.
Coding by hand is always the best.
Why should you know about xhtml/css ?
Here is some reasons:
Respect semantics meaning
DOM compliant (you know the javascript mess)
Easier to maintain
Search Engine Optimization
You still think it takes a longer time to design/integrate a website ?
Think of use vi, eclipse, quanta, and probably some others...
By hand is the obvious answer, because your website/application will be, well, better. (And also because, if you use JavaScript, it's good to traverse through the DOM of a document you've written yourself, versus a generated one that you have to examine beforehand.) But that's mostly only because the visual tools that exist today really suck (I'm thinking of Dreamweaver). It's definitely possible to create a good visual editing (WYSIWYG) program that actually generates good HTML/CSS/JavaScript, but nothing even close has come up yet, so right now hand-coding is much, much better.
I'm not going to read the responses, so its quite possible someone has already said this, but oh well.
First and foremost, you should always write out your HTML / CSS by hand. The reason for this is that no matter how advanced an HTML editor is, it will never be as good as it could / should be. For "good" html / css, you will actually end up writing your page in a different order than what you see.
For example, a page that is displayed like:
________________
|logo |
|----menu------|
|..............|
|...content....|
|..............|
|....footer....|
----------------
"should" actually flow as follows:
<h1>title of site</h1>
<div id="content">.....</div>
<ul id="menu">....</ul>
<div id="footer">...</div>
which an HTML editor would simply throw a hissy fit if you did it through the nice pretty gui. What may be advantageous is to use Web Expression 2 or Visual Studio for its intellisense. It may help speed up (or maybe slow down) your learning curb.
I really recommend Transcending CSS Design if you are already familiar with HTML / CSS. Otherwise grab a CSS book first even over an HTML book. Styling through CSS will teach you proper semantic HTML (or should,anyway).
I like to code by hand because i can keep my code clean and tidy that way. HTML is not very hard anyway.
If you decide to code by hand you will need an editor that supports syntax highlight, and you will need to validate your code as often as possible to avoid errors (this is good practice anyway). This extension for Firefox will ease your work a lot: users.skynet.be/mgueury/mozilla/
I have a horrible habit, actually something I'm wrestling with right this moment, when I think of a better way to do something - either a refactor, or something that would just be SO MUCH COOLER LOOKING, or such a better UX, I just HAVE to do it. Even when it would cost me time and I'm in a time crunch. I never know when to say, "no, there isn't time for this I can do it later."
Is there a line you draw?
Like right now I need a way to display magazine articles that are in the database. The easy way would be to create a new .aspx page and just pass the article id. the AWESOME way would be a jquery fade in modal that would display the article. At least that's what I think. Not being a guru it would take me longer to write. We are launching next week no time for extra crap. However, I just can't bring myself to do it the easy way.
Does anyone else run into this problem? Wondering if more experienced programmers have some wisdom to share.
I'd go the quick route first.
Write an ASPX page that is showing an article based on ID, or even cooler and more SEO-friendly, a slug. You'll be able to meet your deadline. Then, I'd start on the awesome jQuery way.
The bonus to this is that you'll have a fallback option, in case that a user has JavaScript disabled.
You're talking about "gold plating". It's a very common and well-known issue for software developers.
From the glorious founder of StackOverflow himself:
30: Developer gold-plating. Developers are fascinated by new
technology and are sometimes anxious
to try out new features of their
language or environment or to create
their own implementation of a slick
feature they saw in another
product--whether or not it's required
in their product. The effort required
to design, implement, test, document,
and support features that are not
required lengthens the schedule.
The proper way to cure this problem is to volunteer for so much work that you don't have time to do it right, let alone add on extra bells and whistles. :)
Edit: Other "classic mistakes" link here.
I think it's just a matter of setting priorities. Also, if your client, or boss doesn't want you to do things the flashy way, and you don't really have time to do it the flashy way, just do it the simple way, and come back and upgrade to flashy if you have time later. Clients and bosses are usually happier when you finish the work they gave you before moving on to making things better.
I look at how much time I have left, and if I feel I am pressed, I don't venture outside of my area of expertise. I am all for doing it correctly and elegantly, but the reality is that the majority of the time the deadline takes precedence, and I know if I stay within my comfortzone when pressed, I will most likely make fewer errors which means I save the QA people time in testing things.
That all being said, I have been known on more than one occasion to push the limits of how much can be done. If you aren't working an immense amount of overtime already, you can always make extra the time necessary for going the harder route. Yeah doing this can cause a little more work for extra people but sometimes that's the difference between having the best application or having the first loser.
My other advice is don't try and do both options. If you create a basic version stick with it and move on. If you try and do both, you're really wasting time in the end.
The right way is to have it functioning so that users can get to the information they seek. The designer way is to have it kind of working but also have javascript light things up and move around.
The best way is to get it working correctly then revise it. There shouldn't be much refactoring involved if you know where to place things. Obviously retrieving the article is going to be business/app logic and the actual fancy design (like fades/animation) will be part of the design/view aspect of the setup. These portions should be able to sit and be somewhat ignorant of what the other is doing - they shouldn't be tightly coupled.
Sounds like typical feature creep. Convince yourself that tabling a feature idea now to meet a deadline is quite different from simply dropping the feature altogether. You can come back to it months after release and put in new features.
I think you've pretty much answered your own question there. You said that adding this feature would take too much time, and you're in a time crunch and are launching next week. I think it's fairly obvious you need to go the "easy" route.
You're basically describing feature creep. http://en.wikipedia.org/wiki/Featuritis
You need to discipline yourself, what I would do in your position is document the new feature I want to add, and implement it after your out of crunch mode when you have time to work on it. You're obviously aware that adding this feature is going to cost you time and may very well set back the launch of this product, you just need to have the discipline to prioritize and stick with it.
I think every developer has this problem if he is interested in programming and isn't coding just as a way to make money in a 9 to 5 office job.
Here is my advice:
Make a list of every cool thing you think of as you're writing the code. After you have a working basic version, commit it to your source repository.
Now if you have time left go back and do as many cool things as you have time for. Use branch tags if you're going to have to seriously rework the code.
Once you run out of time, if you're doing Agile, write the leftovers up as stories and give them to your project manager or client.
I think when you say you are doing something the "right way" that implies a balance of quality with the speed you can write it in.
If you make something as high quality as possible, but never release it, it's not the "right way". On the other hand, if you write crap but get it out super fast, that's also not the "right way." To do something the "right way", you must balance these two.
An economic phrase that comes to mind is "Quality, Price, or Production Speed, pick two."
Things like this used to absolutely kill me!
Here's my advice:
Do it the easy way (the aspx with the
id parameter)
Write a small proof of
concept to show the client
Show the client the working page and the proof of concept later along with an estimate on how long it will take. The experience of designing the prototype will give you a better idea of what is involved, how to do it, and how long it will really take. The proof of concept can also inform maintainence developers what's what (fading vs logic), and allow them to issolate if the fading mechanism or logic is broken.
Personally, I would stay away from the fading thing. In my experience the client will see no added value in the fading functionality and IMHO seperating it to another page will be easier to maintain. I believe it will be less prone to bugs later since code for the 2 pages will not be intermixed onto one page (if I understood you correctly).
In test driven development approach, when you implement a feature by writing a test for it and implementing it the easiest possible way, you will be able to go back and do it "right" only when you find really need to do so. Knowing this allows you to avoid overdesign. And often, you find you won't need to after all.
While designing my site I am constantly faced with the issue of whether its ok to TAKE ideas and designs from other sites. In some cases there is no distinction in certain aspects. Is there anything ethically wrong with this? Is this expected in the design programming community?
Depends on how much you 'steal'.
Code
If you're ripping off the whole design, then its a bit dodgy. If you like (for example) the Stack Overflow concept of voting up stuff, then steal the concept and use it in a different manner. If you want to know how say the orange highlighting of the up-voted items works, then look at the code. But don't do both and steal both the concept and the design, you'll just create a clone.
Due to the way different web browsers treat CSS and the like, there are often only a very few limited ways to do a particular thing (3-column layouts, etc.). It seems fair enough to blatantly copy in these cases where there is a common way of doing things. Where its something unique, and there's many ways of doing it, it seems a bit more off to blatantly copy.
Graphics
Ripping off graphics - not so okay. Images have been around a lot longer than code so copyright law, etc. probably suits them better. If nothing else you have to contend with possible watermarks or other metadata to identify the original source. It's very easy to check for image stealing, less so for code within a larger block.
I'm a coder, not a designer so what I tend to do is borrow graphics that I like just while mocking up my web-app for internal use. Does that seem fair? I'll change them for newly-designed or paid-for ones before going live. At least that's the idea, though it could be far too easy to forget and use them by accident.
That's the way it works in the newspaper world (well it used to, not sure now with the advent of this there Internet thang): You download as many graphics as you can bother waiting to come over your 57.6k modem; you only pay for the ones you actually publish.
Oh, this is a hard question.
On the one hand stealing is wrong, on the other hand you are obliged to save you employer money by solving a task quickly.
My only advice is:
If it feels wrong in your gut, you probably stole too much.
I think most designers and developers draw a distinction between 'creative inspiration' derived from someone else's work and blatant plagiarism.
I wouldn't think twice about peeking under the hood to see how someone had done a particularly nifty javascript effect, or implemented a tricky piece of css elegantly, but I'd find it distasteful to blatantly cut and paste that same code for use in my own development.
I'm not learning anything by just grabbing and reusing - although I think it's fairly standard to have the same code to hand as a rough scaffold from which to explore my own way of implementation. I think that's the way a lot of people work.
I am a web developer, not a designer. As such, I have a sense of taste, but not the ability to come up with something wholly on my own. As a matter of ethics, everything commercial or with the expectation of serious traffic that I do, I will hire a designer. They need to eat too, and there is something wrong with making money off of others work and not compensating them for it.
If it is small, personal, or an internal throwaway type thing, I will rip off things like color scheme and/or layout. Technically you could say this is stealing, but I think of it more as "imitation being the sincerest form of flattery" thing. I don't feel that bad about it since there isn't really any money to be made in it.
I think its ok to steal ideas, but not to steal code.
This is how a lot of design is accomplished. Except it's obscured by lots of lifts, not a single wholesale lift.
Stealing resources (graphics, code) is not really OK if they're not specifically marked as free/open/creative-commons/etc. Stealing design and layout is a bit sketchy if you're just xeroxing the same layout using your own code -- using someone else's design as a starting point is one thing, but don't just recreate their design verbatim. Stealing snippets of code for specific bits of functionality is fine (IMHO) since even if you grabbed a reference manual to learn it from scratch you'd end up with the same thing. (Think: javascript for changing an button image on mouse-hover)
Having said all that, imitation is the sincerest form of flattery. Don't steal resources, but using other sites as "influence" should be OK. Or, if in doubt, ask the owner of the site you intend to use as reference/influence.
It's almost like everyone answering this question forgot what it was like to work with web pages between 1995 and 2002 or so. Stealing was a way of life for tons of designers during that period. The key was, and still is, to take only what you need, and to make sure that you understand it well enough to make it from scratch the next time. Who knows, you might improve something in the process.
There's an old saying I was once told: Good designers create. Great designers steal.
That said however, you should never blatantly rip off code if you can avoid it. Look at it, understand it, rewrite it (or improve it, if possible; even if it's only something like using what you find are better variable names) but never just copy and paste. Same goes for layouts; take the layout and modify it to suit your needs - it might end up looking similar (look at all of the Basecamp-style clones out there as far as UI goes) and that's no big deal at all; plenty of sites look similar. The key is to go into the situation looking for inspiration and not some code to yoink. If you can use the code as-is or with little modification then you really have no problems, but it shouldn't be your intention to find someone else's code and rip it off.
It's a sliding scale. Borrowing just an idea is one thing, if you're incorporating it into the rest of your existing design, not just wholesale copying an idea. Snagging a idea for a design element is fine, copying a whole design exactly is not. As you borrow more and more of a design, it gets into the not acceptable category. Copying directly is also another factor. If you see something you like and reimplement it for yourself, that is typically fine. But doing a direct copy of code, images, or css not so much.
For the most part, ideas are fine to take and implement. If people couldn't take existing ideas and expand them or re-implement them, we'd never have gotten out of the dark ages.
If you feel the need to steal code because you can't code HTML/CSS well or don't have an eye for design, steal from a place that explicitly permits you to use their design/code, like OSWD. In general, stealing HTML is fine, but ripping off CSS wholesale is a no-no. Just because you can easily view the CSS source doesn't mean that it's ok to just copy and paste it.
Don't steal graphics, period. Especially things like photos and logos and icons. If you need that sort of thing, purchase stock photography or take your own photos.
When in doubt, ask the owner of the site.
Stealing code or designs is immoral and in some cases illegal.
Taking inspiration or copying functionality is less of a problem. For example, at some point in time someone realized that putting a "Forgot Password?" link next to all login forms is a good idea, now everyone does it. It's not theft it's just replicating a good idea.
I'm not a web developer, but I might have some insight that will help as well. My team has created several applications that have served as the starting point for other applications delivered to various customers.
The successful derivatives were those in which the developers took the time to learn the architecture and why things were the way they were. They then took the more crusty parts and rewrote them and in general expanded and improved the architecture.
Invariably, when a team simply took the existing project and tried to 'brand it' or copy it for a customer without actually figuring out the systems, they either created poor implementations of the extensions or had the project fail outright.
I realize this is a bit off the main topic of the ethical issues address by others here just fine, but my bottom line is that pure theft usually costs you more time than it saves.
Whilst working on some generally horrible Javascript code this morning, I came across the following (in multiple places):
// make moveAmount negative
moveAmount = moveAmount - (moveAmount * 2);
I sit directly across from the guy that wrote this; he's been a developer here for seven years. I, on the other hand have just started, am pretty junior and don't claim to know jack.
Nevertheless it has got me wondering about the guy's contortions of simple logic after so many years developing software.
My question is what view others here might take of the overall competancy of a developer that wrote this (3 weeks ago), or does it even reflect at all?
Would anyone point out the convolution?
I, myself, work in constant dread that such judgements be made of me.
Simple solution: Show him the line of code and ask why he did it. It's an opportunity for both of you to learn something. Maybe there was a bug in a browser or some other issue (rounding comes to mind) so the code might break without this. Or he made a mistake. Either way, asking will clear this up.
And while you're right that other people will judge you from the code they see from you, that is not the only thing they take into consideration (and if it is, then you're working at the wrong place -- leave while you're still sane). They will also see when you're polite, curious, helpful.
These things count more than the code you write: Code can be fixed much more easily than angry co-workers.
Your example may be poor code, but I've seen worse (after all, there are circumstances where it will work; some code can't even say that). I think the question you're really asking is: is there any line of code so awful that it means the developer can be deemed incompetent on the basis of that one line?
I say no. I have two children who were terrible sleepers as babies. I've come to work with the flu. I've been at work in death-march mode where I've been working twenty hours in a row. In such circumstances anyone can write a terrible line of code. (This is why such circumstances should be avoided.)
Granted, I would hope I would spot the dreadful code later, and fix it.
Well it works so you would just look like a p**** if you told him that you dislike that code and probably rightly so :) Then again he might have done that code 7 years ago as the very first JavaScript he wrote, but seriously never judge someone from just ONE LINE of code.
Regarding the fear of judgement, relax. It's true, we're all going to be judged by someone at some point, whether it's some pointy-haired boss or maleveolent little upstart. The main thing to get to grips with, I think, is how to get something useful out of every such encounter.
Obviously, there are going to be people griping about things for the sake of it, but you'll also find many similar situations where there's something to be learned.
The suggestion above to start a dialogue with your co-worker is excellent; it may directly feed into just such an encounter, from which either, or both of you, may learn something important.
It's tempting to find one example and generalize about a developer, but unless he has a track record of this sort of nonsense, I would consider it an isolated incident. Simply ask him why he didn't write :
moveAmount = moveAmount * (-1)
this behavior is different from
mountAmount = -moveAmount in the case where 2*moveAmount may cause an overflow if moveAmount was big enough (like 2^32-1 for example).
I don't know if that was his intention though.
Since he wrote it 3 weeks ago, I would say he should be open to criticism for this line. It shows an immaturity that is really inexcusable after 7 years of working professionally.
If he would have at least done this:
moveAmount -= moveAmount * 2;
He would have gotten less flack. It at least shows that he's aware of the other operators and is making some effort to make things more readable.
I don't think that you can always judge people with one line, but the code can tell you so much about a person's aptitude that one line can tell a lot about a person.
I say it will depend on the swallow. If isolated, the line of code you've shown is something I would expect from an exhausted programmer, even if a very competent one. It is an example of something just not very clever and tired people do not so clever things. If, on the other hand that kind of code appears frequently then probably you're working with someone with a twisted mind.
Things that are obvious indications of a bad programmer are related to bad practices. Good programmers will not make huge methods. Even tired, they will try to keep their types loosely coupled. They will avoid exposing public fields instead of exposing them through accessors or properties. They will try inheritance and aggregation as forms of code reuse rather than repeatedly doing copy-paste... The list is long. Those are the kinds of swallows that lead me to almost instantly feel it is summer. :-)
If he wrote that when he was first beginning, he gets a pass. If he wrote that recently, he gets a thumbs down from me. The overall competency of the developer is definitely suspect.
Others are saying you can't judge a developer by one line of code, but I say it can certainly cast doubt upon his competence. I'm not suggesting you jump to conclusions, but that type of code is certainly evidence of a mediocre developer at best.
... and as for it being related to being overtired or stressed or whatever... the bottom line is that code quality is important. If he wrote a one-liner like this, what else may have been written that doesn't stand out so easily?