Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I tend to think very independently, often coming up with unconventional, sometimes unorthodox, ways of solving problems. I do not like to listen to authority, such as having to write code a certain way or following strict guidelines and formats.

Would the software engineering field be tough for someone like me? If not, what fields of computer science do allow for that?


migration rejected from May 11 '15 at 2:11

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by Ixrec, MichaelT, jwenting, durron597, Snowman May 11 '15 at 2:11

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – Ixrec, jwenting, Snowman
If this question can be reworded to fit the rules in the help center, please edit the question.

This looks like a much better fit for Programmers.SE – Jerry Coffin Feb 10 '11 at 4:12
I feel your pain too. – Job Feb 11 '11 at 2:22

Being unconventional is a doubled-edged sword. You may be able to solve problems others can't or solve the same problems more efficiently, but...

Much convention is convention for a reason. If you are going to deviate, make sure you understand and can explain why your way is better. Even being no worse may be insufficient justification, as others who are versed in convention may have to follow your work in the future.

As an anecdotal example, I personally tend to have difficulty sticking to standard names for common design patterns, and often invent descriptive phrases. I may feel they are as/more accurate (and often it means I derived that pattern on my own from first principles), but it makes communication difficult and I give off the impression that I'm ignorant of the pattern simply because I name it differently.

Back to the point: if you deviate from standard practices in ANY industry, you'd better be able to back it up on a case-by-case basis. And then stop and think about why you are deviating. Are you SURE that your way is better than the standard practice? Just saying "I'm a creative, independent genius!" is insufficient.

+10, if I could. Before you ever go at an unorthodox approach, make darn sure you completely understand the orthodox one. Then make sure you can explain exactly why yours is better. I've been burned by many "creative" solutions that turned onto necessary complexity and piles of code smell. – keithjgrant Feb 10 '11 at 7:14
+1 agreed completely. To put it in another way, we are in this industry to solve problems. Being unconventional is good as much as it helps you solve problems better in a demonstrable, provable manner. But being unconventional for any other reason / with any other result may easily contribute to the problem rather than solving it. – Péter Török Feb 10 '11 at 8:55
One rule I've tried to impress on my son: "Never break a rule you don't understand." – David Thornley Feb 10 '11 at 21:33
"Your manuscript is both good and original; but the part that is good is not original, and the part that is original is not good." -- Mark Twain – Mason Wheeler Feb 11 '11 at 0:41

Any corporate environment is going to be very tough for you, my friend. While engineering, in general, highly values independent thought and work - teamwork and interdependent skills are often more highly valued.

Independent workers can be trained, and in some specific industries are a dime a dozen. Teamwork is what gets the gold.

That being said, a good software engineering team will allow for a lot of latitude and input from its team members, so someone like you may be able to voice concerns and get approval for doing things Your Way. However, you must learn to be flexible with your boss or manager's wishes as well.

It is true that big corporate environments on average tend to be more restrictive than small companies. However, there are huge differences between corporate and corporate (and small company vs small company). In some corporates I enjoyed much more freedom than in some small companies. – Péter Török Feb 10 '11 at 8:50

I'll play devils's advocate here:

I tend to think very independently, often coming up with unconventional, sometimes unorthodox, ways of solving problems.

This sounds like you usually find unnecessarily complex solutions to problems that can be solved more elegantly. Solutions so complex noone but you can understand them. And that makes you proud because you're so much smarter than everybody else.

I do not like to listen to authority such as having to code up software a certain way or following strict guidelines/formats.

This sounds like you usually write "crappy" code. Dangling pointers, inconsistent indentation, global variables named u, v, w... And you think you don't need these useless guidelines because you're so smart.

< /devil's advocate >

If any of that description fits, you may have a great future in software development. But you'll have to learn that you can write even greater programs if you follow the sensible guidlines where they make sense. Things that are just useless for a 10 kloc program (like worrying about dangling references, variable names, indentation) suddenly become very imporant when you're working on a 100 kloc or 1000kloc program. And you'll have to accept that it takes years of practice before you can judge where the guidelines make sense and where not. Until then, you'll just have to apply them everywhere. Or write crappy code.

My advice would be to find the most complex field you can find (that interest you): e.g. compiler building, machine learning, AI, symbolic mathematics. It's a very humbling experience to find a field where you really have to study hard to understand everything. And to see how much smarter the people who invented all the things you're learning must have been. If you're as intelligent as you think, you can have a great future in that field!


As with many things, you'll have to stike a balance between adapting an existing solution and thinking up a new one. While it is important not to reinvent the wheel, if everybody took this approach, we'd probably all still be coding in ALGOL.

A good way to find this balance is to do a quick mental cost-benefit analysis: is the extra effort required for an unconventional solution going to bring a big enough benefit to warrant its use?

On risking of going too Zen on this subject: don't strive to think outside the box, think inside the box and don't stop when you stray outside.

On coding conventions, I'm afraid there is no excuse here: you simply have to toe the line. Minor deviations will be tolerated but coding is a form of communication, so if your code isn't understood by others, you'll end up coding for yourself and there's very little money in that market.


I disagree with aqua.

Good software engineers (or programmers) are a creative bunch, slightly rebel.

The way to manage this rebeliousness in the corporate world is to give enough of what the system wants from you (that's what they pay for), then give some more in terms of occasional unexpected results and benefits (that's what will keep you in the job long), shut up and do your own thing when you have a bit of spare time (that may keep you in the job even longer if you show results of those explorations at the right time and to the right people).

Software engineering is great for creative people. This includes programming, being a SW architect and many such things.

Now quality insurance / control is a lot less pleasant for creative people. However you can also get your kicks there if you find yourself a niche where you can express your creative problem solving skills.

The trick I found is to essentially do what you are asked to do in less time than required to do the job, but not say that and use your spare time to do what you want to do. Use your creativity that way, but don't abuse.


What most companies prefer is someone that is able to do all the technical stuff really well, but that can also work well in a team environment.

Most of the time, you'll be working with other people, and getting along with them is key.

Guidelines/formats are there to provide a common approach across all projects, whether it be architecture, language choice, framework choice etc.

It's a fine line. You may be the smartest guy out of 100 coming in for an interview, but maybe the 2nd smartest guy with better team skills would end up being the better choice.

As for fields to work in? Maybe research would suit you?


I'd suggest a couple of different areas within the field that may work better for you:

  • Academia - If you are quite brilliant, this could be the place for you. While there may be some rules like having to teach a class every X semesters or acquiring grants to fund your research, there is a great deal of autonomy that can come if you become a professor somewhere.

  • Small company - In this case you may have the freedom as you are the whole IT department for a company. Having such a diverse workload can be a two-edged sword of course but this also true of most things in life.

I'd also wonder how long have you been in this field as I could picture those with little experience have your kind of perspective that after a few projects where there was a lot of chaos and much unorthodox practices, you may want to see some structure and rules soon.

"Dan Pink on the surprising science of motivation" is a TED Talk that points to Autonomy as one of the better motivators when it comes to creative work so in a sense I don't think it is bad to want autonomy though it does tend to require some negotiation at least in my experience.


If your software has to be read by others (like a team) or you intend to work for a boss, you will not be happy. Most projects need discipline, guidelines, methods and standards to work. You have to follow all the above and in times pretend to be happy about it.