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?
Related
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
how would you handle a client who wants you to implement a website layout that looks horrible and is wrong in many many ways, when they absolutely think it is great, really "different" and cool and since you are a programmer, you don't know anything about design.
i have tried arguing, reasoning and not caring, but it pains me physically to think that i should put that online... any tips or experiences would be great! thanks.
update: things are even a bit more complicated, since it is not just any client but a business partner with a great business idea, that i want to be part of...
Craigslist.com is one of the most visited websites on the planet. Yet its UI is appalling by most modern aesthetics.
This isn't a technical issue, but a business issue. You need to sit down with your business partner and put forward your point of view convincingly. If you're going to work with her in the long term, then you both need to find a way of resolving issues and coming to a compromise. Look at this dispute as a warning sign about the business relationship.
I've some experience with what you describe. I usually try to convince them their design is not as good as they think. Things like usability, navigational structure can help you in the argument. I've noticed that showing some heatmaps of how people look at websites can have a nice result. "I never looked at it that way"
If they however insist on the bad design, you have roughly 3 options:
Politely tell them to find somebody else to create the ugly site for them.
Make them sign a document that states that you strongly advised against the design and that they cannot hold you responsible if they get bad results or comments
Bow your head and build it.
Option 1 can hurt your reputation just as bad as option 3.
Option 2 sometimes convinces the client that they might be wrong after all as it is now written on an official looking piece of paper they have to sign. But a least ensures you can work with a clear conscience; you warned them, they wanted it anyway.
Good luck :)
He who pays the piper calls the tune.
Depends how much the coin matters.
Managing difficult clients is something you need to come to terms with, as a freelancer, or any sort of sufficiently experience professional.
If you don't like the design, you can have a simple thought: Do I need this client? If not, drop them. If you do, then just accept that you don't always get things your way, and deal with it.
If you don't want your name attached to the work, you can easily come to that compromise.
Sometimes you need to make moral choices about clients as well; in this case you just have a subjective art choice; I think it is easy enough :)
I have had some cases as you describe. Just keep in mind that you are creating something for your client, it's the client that will work everyday with the application and it's the client that need to be happy with it, not you :)
There have been a lot of answers that boil down to:
Just do it for the $$$
Do a mock up of something better
Run a usability test
Run like hell (but politely)
All of these assume that:
The design really is bad
You are objectivly approaching this project
Please don't hear what I'm not saying: I am not saying your premise is wrong.
First, I am saying its worth considering that it may not be that bad. There are a lot of very successful sites out there that drive designers nuts. If it doesn't satisfy a need, it won't matter how well its done.
If you want to be a part of this than you need to look at the business plan first, and see if its valid, and if the site will fulfill it. If either one of those is a no-go, than fix those problems first.
Second, ask your associate if (s)he's considered other designs. Ask for the sites they used to come up with what they want, and ask what else they've considered.
If they give you something, look at what makes those good/bad and see if between the two of you you can come to a better design.
If they can't, then tell them that with some work there may be something better and work together to create 3 or 4 mock ups. Then whip out the usabilty test. Even if you've done them before, I highly recommend reading what Jakob Nielsen has to say about it over at http://www.useit.com/alertbox/
Since this seems to be a business partner, just doing it for the money and/or running like hell doesn't seem to be an option. Working through this with a little more give and take may help, but if you can't come to an agreement, then you probably ought to leave.
Ask users that match targeted audience
Why don't you create a mockup of a particular part of this app/site and try asking a few people that represent the persona of the product. The targeted audience. Give them two possible choices and let users decide what will make business value instead of you or the client.
Be careful since the first thing I would do when coming to such a website is to look who's the webmaster that produced that site. And then if I would see your logo below it wouldn't impress me. It's not for your good reputation.
So as a professional in that area, I would try to discuss the design with your client, offering him your knowledge about good website design, since that may be also part of the service you're offering.
If you really need the money, just do what he wants and take the cash. Avoid your name appearing on the site anywhere.
If you have other work lined up, tell the client you think he would be better off with a different designer that can meet his needs and say goodbye.
My experience of this kind of client tells me they are a royal pain the arse, with endless tweaks and adjustments to the design. Get out while you can.
Do it. In your own time do your own version - as you want it to be great, which you do as you have a stake in it (you want to be part of it). Show them the better idea. Make them buy into it by making them feel part of it, not that you have done it behind thier back. the idea just came to me and I done it. If they don't like it tough – you could never have won. However they might just be impressed at your effort and/or initiative.
I'd say do it but put nothing identifying you or your company on it, and keep it the hell away from your portfolio. Also have very explicit conditions around ongoing support for it.
Maybe you could bring in a third party, someone whose opinion on design and suggestions for improvement your business partner would respect -- maybe a graphic designer or a web usability expert. That way, you might be able to salvage this business opportunity without alienating your business partner.
I agree with others. If you don't need the work than politely decline. If you do, release what the client wants and make them pay for every tweak after launch once they realise the design sucks.
Perform usability tests. Create a mockup that's fairly close and get people involved from the target audience. If they are a designer then they should understand that this is a sensible approach. Be careful to introduce it as best in both your interests.
The key is to get independent feedback. That keeps you sweet with your business partner and you also get a good design.
If it's a bad design and it's being pushed, then it's someone's "baby" and you can't touch it.
It won't matter how good your alternative is. It won't matter if you can point to the exact same site in, "Web Pages that Suck." It won't matter if senior executives quietly say, "Wow - I really like the alternative - it makes us look Fortune 500!" It won't matter if you bring surveys, focus groups, or if Jesus, Himself, shines the light of truth on your alternative and blesses it: you'll be branded as a, "non-team player," and the cruddy site will STILL be posted.
Then, in 18 months, after you're gone and the three people who were hired to replace you EVENTUALLY cough up a site with minor, almost embarrassing, changes that actually make the site resemble an ad for adult incontinence products, you can come back to this post and say, "Hey - thanks. You... were right."
I want to add an Link to my question:
Storing Password in Databases in plain text vs Customer Needs
In some cases it is the same issue. There are customer needs that are not acceptable. the answer provided in that question maybe help you find a way around that problem.
I think I've worked with this person before, when a university website was being designed by committee. We had two people come up with designs, and the initial vote went 12 to 1 ... the one who was ahead was done by a professor of commercial art, who couldn't care less if you didn't like his design. The other one, though ... she had to come out and defend every little aspect of her design. The revote was 1 to 12, as I refused to change my vote.
Luckily, three of the people from the graphics department came up with a new design, and presented it at the next meeting, and everyone agreed it was better, so we were able to torpedo the blinking splash screen and George Washington's hair design.
Anyway, the point is -- you have to find out why she prefers her design, and then come up with something that takes each of those points, but doesn't suck. Unfortunately, it might take someone with design experience to manage to put it all together -- but if you're planning this to be a business venture, it might be worth spending some money on.
Here's my suggestions:
Why is the design bad? Make sure you understand why before you get into this conversation. Remember, there is some business goal behind having a website. Understand that, and use it as your point. If you don't know what the goal is, ask. If they don't know what the goal is, help them figure it out.
Offer alternatives. Point out the positives and negatives, and help them understand what the tradeoffs are.
Mockups and tests. If you can, mock up the alternative, and let them see the differences. Get potential users to try them out if possible. If not, at least have the customer use the mocked-up website as an actual customer, trying to fulfill an actual scenario.
Good design is the design that will meet the stated business goals of the customer (assuming that this is a business website).
Also, understand what your job is. Is your job to help them solve a business problem, or to implement a specific solution they have in mind? Understanding their expectations of you may help significantly.
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.
The second part of that question is key. If you are one of a few programmers, and after banging your head on your keyboard for endless nights you can't figure something out, with no one else in your organization to ask, what do you do? Not having someone to ask has more to do with the fact that it would take too long to bring them up to speed to even have them assess the problem. Are these the instances where you have uncomfortable conversations with management and tell them a third-party contractor with more experience will be required?
There is a time and place when everybody hits a problem where there doesn't seem an obvious way out.
1) Ask yourself if you are the first person ever to solve this - if not, then there is likely to be an answer out there. Try Google, SO etc.
2) Take a break and try and do something else for a while - it's amazing what a few hours away from the keyboard and thinking about something else can do.
3) Try talking about the problem to someone else, even if they aren't technical - sometimes the process of explaining a problem to someone who isn't technical or involved can lead you to the right answer or an approach from a different angle.
4) Admit it's harder than you had envisaged or you are stuck. A good boss will help you get to the right outcome, for both you and their business. Make them aware of the effort put in and the conclusions and decisions you've made to date.
5) If all else fails, help your boss choose the contractor as you'll probably have to maintain their code :-)
My favorite is rubber ducky debugging, explained here:
http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html
We called it the Rubber Duck method of
debugging. It goes like this:
1) Beg, borrow, steal, buy, fabricate
or otherwise obtain a rubber duck
(bathtub variety)
2) Place rubber duck
on desk and inform it you are just
going to go over some code with it,
if that's all right.
3) Explain to the
duck what you code is supposed to do,
and then go into detail and explain
things line by line
4) At some point
you will tell the duck what you are
doing next and then realise that
that is not in fact what you are
actually doing. The duck will sit
there serenely, happy in the knowledge
that it has helped you on your way.
Works every time. Actually, if you
don't have a rubber duck you could at
a pinch ask a fellow programmer or
engineer to sit in.
Andy
Some times if I can't come up with a solution it might be because I am headed the wrong path with my approach to solving the problem.
It helps me a great deal to not think about the problem for a little bit. Coming back to it after a break can give one fresh insight that might help find a solution.
Depending on the problem sometimes I develop one-off apps to test/work with that particular feature/bug/whatever without all of the other pre-conditions and dependencies that exist in the project (and could be affecting the result).
Try redefining the problem. Sometimes you can rework the software you're writing so that you don't encounter the problem that you're trying to solve. Somtimes it's not a problem with your solution, but instead the state of the software that you're trying to implement it in.
First I google
And if that doesn't help I try to split the problem into parts I can solve. Usually the insight I get doing those parts will enlighten me sufficiently so I can take a new stab at the difficult part.
I like to start working on the easiest bits first. So what if you can't figure out how to find the optimised path algorithm in your map? Just start by writing the flood-fill drawing code. Then do the AI routines for combat, after all they need to get done as well. Then while you are working on the weather simulator, you will realise that your subconscious has been working out the details for the pathing algorithm while you slept.
I faced this situation for an entire project in which I was the only programmer on the job, responsible for architecture all the way down to maintenance.
I dealt with it by aggressive use of Google and programming Q&A sites, though I didn't have SO at the time (resorted to Yahoo! Answers a couple of times). Most of the time I wouldn't find exactly what I needed, and I had to use my brain and do some hard-core trouble-shooting to solve most problems.
When you get absolutely stuck behind a brick wall, you need to come up with workarounds that are satisfactory for your end users. Chances are you won't be able to make everything work by sheer force of programming.
I agree with another answer here that sometimes getting up and walking away from a problem will often provide you with flashes of insight that would never occur to you while you're behind the keyboard. I have often had my most brilliant ideas come to me while driving or in the shower.