Should I continue my self-taught coding practice or learn how to do coding professionally?

Question

Lately I've been getting professional work, hanging out with other programmers, and making friends in the industry. The only thing is I'm 100% self-taught. It's caused my style to extremely deviate from the style of those that are properly trained. It's the techniques and organization of my code that's different.

It's a mixture of several things I do. I tend to blend several programming paradigms together. Like Functional and OO. I lean to the Functional side more than OO, but I see the use of OO when something would make more sense as an abstract entity. Like a game object. Next I also go the simple route when doing something. When in contrast, it seems like sometimes the code I see from professional programmers is complicated for the sake of it! I use lots of closures. And lastly, I'm not the best commenter. I find it easier just to read through my code than reading the comment. And most cases I just end up reading the code even if there are comments. Plus I've been told that, because of how simply I write my code, it's very easy to read it.

I hear professionally trained programmers go on and on about things like unit tests. Something I've never used before so I haven't even the faintest idea of what they are or how they work. Lots and lots of underscores "_", which aren't really my taste. Most of the techniques I use are straight from me, or a few books I've read. Don't know anything about MVC, I've heard a lot about it though with things like backbone.js. I think it's a way to organize an application. It just confuses me though because by now I've made my own organizational structures.

It's a bit of a pain. I can't use template applications at all when learning something new like with Ubuntu's Quickly. I have trouble understanding code that I can tell is from someone trained. Complete OO programming really leaves a bad taste in my mouth, yet that seems to be what EVERYONE else is strictly using.

It's left me not that confident in the look of my code, or wondering whether I'll cause sparks when joining a company or maybe contributing to open source projects. In fact I'm rather scared of the fact that people will eventually be checking out my code. Is this just something normal any programmer goes through or should I really look to change up my techniques?

Answer 1

In fact I'm rather scared of the fact that people will eventually be checking out my code.

Good. Being conscious that people are going to look at your code will make you try harder.

Programming has become an incredibly large field. There are dozens of topics, tools, niches, and specializations, some of which are whole careers unto themselves. There is a vast amount to learn and know, and when you work with other programmers, there will always be stuff you know that they don't and stuff they know that you don't. This is a good thing.

If you are worried that your experience is incomplete, there are plenty of steps you can take to amend that through formal education and collaboration with trained experts. But it sounds like you're afraid there's some quantifiable milestone after which people say "Okay, now that I've mastered that, I'm officially a programmer." There is no such milestone. I've definitely had moments where I thought "yeah, now I'm getting somewhere" after I learned something new, but there's no magic list of things you must know and do to call yourself a programmer.

I know a lot of things about programming, I've used a dozen languages in lots of projects, and yet the subset of programming knowledge I can call my own is tiny. And I like that. Frankly, a programmer isn't something you are. A programmer is something you are constantly learning to be.

Take honesty inventory of your skills, your strengths and weaknesses. Get feedback from people with more experience than you. Look for positions that line up pretty well with where you think you are - but don't be afraid to go for jobs that are a little outside your current mastery. If you only take jobs you already know everything about, you'll never learn at work.

Answer 2

When you begin developing applications in cooperation with other developers, some of these personal style foibles are going to get in the way.

If you begin working at a shop that uses underscores, you are going to use underscores. Everyone, regardless of their previous background, follows the shop standard for coding style.

Unless your coding style is extremely obvious, you'd better get used to writing clear, concise comments explaining how your code works, so that other developers can follow it.

If you don't know anything about unit tests, buy a good book. There are plenty of good books on unit testing out there. Same with MVC.

Professional software developers know how to play well with others, without littering the sandbox. The very best ones know how to read and write code regardless of style.

Answer 3

Programming has an art component and a discipline component to it. The art component is in thinking up best approaches and implementing them; the discipline is in making sure that you did it correctly, and that others can understand your code and enhance it when necessary.

The art component is fun: you do it because you enjoy it. Naturally, that is the part that you teach yourself first.

The discipline component is more of a nuisance: you do it out of necessity. It is a vital component of working in a team, though: you cannot get away from doing it, at least to some degree. Once your code is integrated with that of your teammates, your flexibility to "change things at will" takes a nose dive. Yet you need an ability to change your code with confidence in response to changing requirements, or to address bugs. This is where various "boring" tests come in: with lots of tests in place, it is easy to check if your latest change breaks things or not.

Code style gains importance, too, because adhering to a common style makes the code easier to read for everyone. In larger companies you would find nightly jobs that test compliance with the coding standards automatically, and e-mail you nasty warnings when you deviate.

Back to your question, concentrating on the art component is a natural early stage of programmer's development. It can take several years of working in the industry before you start appreciating the discipline component. You do not need to actively look to "changing up your techniques", though: they will morph naturally in the process of working in a team.

Answer 4

To your question, yep you should always be looking to change your technique, to embrace the unique project and emerging technology.

@assfallows's point of "Frankly, a programmer isn't something you are. A programmer is something you are constantly learning to be." is really the be all and end all of coding.

Its great that you are noticing areas where you do something different from others, especially when you see it is a standard. You have spotted Unit Testing and MVC - and now your next step must be to learn about them. See how they work, what you need to implement them and try and get a sense of when it is a good design to implement them.

This is a constantly evolving field with new languages and patterns rising and falling. If you are comfortable with the coding aspect, start examining the design part. Learn what makes them good and when to use them.

Certainly joining a team is a great benefit - you always need other eyes to look at your code to spot areas you rushed or did not think out the full implications.

Answer 5

You don't need to be a greater commenter. But you should be a good commiter (yes, start using some sort of VCS - I recommend Git).

Style is a thing that ALWAYS evolve. Don't worry about it. You'll learn what is a reusable code and what's not. But you have to practice and to get help for it.

Try helping in some Open Source project on Github. Some people are really nice there, and will try to help you. This is the best tip I can give to you.

Answer 6

In fact I'm rather scared of the fact that people will eventually be checking out my code. Is this just something normal any programmer goes through or should I really look to change up my techniques?

How would you know what to change without some feedback from more experienced programmers?

Having other people review your work can be daunting, especially the first few times, but it's the best way to get the constructive criticism that you need to improve your skills. There's a SE site for code reviews that you may find helpful. Asking smart friends to look at your code is another good way to get some feedback.

Answer 7

The most important thing is to develop flexibility. The more familiar you are with fundamental concepts, the more responsive you can be in any language, programming approach, style, or environment.

Mastery is less about learning every /thing/ there is to learn, and more about learning /how/ to go about solving a problem, in a variety of situations.

And the best prescription for that is practice. You should always have a project; if you're between paid gigs, take up a personal toy. Spare time one weekend? Work through the 'hello world' for a language or platform you've never used before. Look for ways to learn a lot at once. For example, build something in Google App Engine, and you'll learn all at once about Python, BigTable, and column-oriented databases. You'll get a good dose of "professional" Google style as well.

A good general knows how to apply his learned tactics and collected experience in a variety of terrain. It sounds like you have some tactics and experience, but you need to encounter some unfamiliar terrain. That's probably the single best way to ascertain what you know and what next you need to learn.

And if "professional" style is what you're after, take on some "professional" projects. Find an open-source project you like, assign yourself a change to make, and set about it. Be prepared for jackass reviewers, but remember that the majority of folks in this field didn't get where they are for having smooth social skills. The point is to expose yourself to as much of what you want to be as possible. And you have to build yourself up well enough to do it yourself. No class can really teach you. In fact, there's too damn much class-learning going on today, and not enough solid real-world competence.

Answer 8

It's left me not that confident in the look of my code, or wondering whether I'll cause sparks when joining a company or maybe contributing to open source projects. In fact I'm rather scared of the fact that people will eventually be checking out my code. Is this just something normal any programmer goes through or should I really look to change up my techniques?

In my opinion, there's no need to worry about what others think of your code if you focus on objective measures of the quality of it. Is it

• Correct?
• Understandable?
• Maintainable?
• Efficient?

As a first principle, It should always be your goal to focus on objective qualities, rather than others' opinions. Focusing on others' opinions is the path to mediocrity, and, as you're experiencing, anxiety.

The only reason to be concerned with others' opinions is to be able to integrate well socially (or in a work environment) with them. If you have in the forefront of your mind the goal of improving objective qualities of your work, then there's no need for feeling scared about others' reactions -- they're just opportunities to learn or, at the worst, practical details to deal with.

Be true to yourself!! Continue learning and enjoying what you do.

Answer 9

You remind me of my self after going to college to be a Software Engineer. If you want to be a programmer I would say take a position. You are going to need to comment your code, write unit tests, understand, fully, object oriented code. But right now you have no real reason to do so. As long as you are just working on personal small projects. Where you don't have to answer to any one but yourself. You will not grow any further as a developer.

By taking on large projects that many people are working on and having to answer managements questions like "Is this release bug free? Because we are going to releasing it to the customer.". You will grow as a programmer / engineer. You will get some hard knocks. You may find the things you mentioned more valuable and you may find new things that no one has though of before. You will grow.

Even my college failed to teach me these things even though they tried.

For Unit Testing look for Test Driven Development.

For Commenting think of code that you have written after your gone. And the time other people will spend reverse engineering it.

For Object Oriented Languages. Understand it at least. It's a tool that you can use to solve problems in a more readable fashion.

Good Luck :D

Answer 10

In short, the best way to learn is generally to hang out with someone you can learn from. If you feel that your skills aren't up to scratch, hanging out with people who are better than you is the best you can do. Certainly much better than withdrawing and isolating yourself further.

However, I think you're painting a very simplified and misleading picture. Far from all "professionally taught" programmers are really any good. Just because they do something doesn't necessarily mean it's the right thing to do.

And much (but not all) of what you're saying really sounds like you're the one who could teach them a trick or two.

I lean to the Functional side more than OO, but I see the use of OO when something would make more sense as an abstract entity.

That sounds great to me. The best coders are the ones who use the right tool for the job. I'd always pick someone who knows both paradigms, and uses each of them where it makes sense over someone who religiously uses only one paradigm.

Next I also go the simple route when doing something. When in contrast, it seems like sometimes the code I see from professional programmers is complicated for the sake of it!

Again, simplicity is good. Don't make your code complex until it needs to be complex. Some people do tend to make things complex out of some misguided idea of elegance, or because "we'll need this additional functionality later". Generally, it's better to do the simplest thing that solves your problem.

I use lots of closures. Good. That's why they're there. They do scare some people who got stuck in the 1990's and Java's outmoded quasi-OOP model, but really, that's their problem.

And lastly, I'm not the best commenter.

What should be commented, and how, is highly subjective. There's no real "right" or "wrong" there, but when working on a team, it's important to write code that the entire team, and not just the author of the code, can understand. And sometimes, compromises have to be made to conform to the team's coding style. That doesn't necessarily mean that you should write more comments, it simply means that it's something you and your team will have to agree on.

I hear professionally trained programmers go on and on about things like unit tests. Something I've never used before so I haven't even the faintest idea of what they are or how they work.

Well, ask them. :) Testing your code is essential, and unit tests are a popular and useful tool for this.

Lots and lots of underscores "_", which aren't really my taste.

As with commenting, that is subjective, and depends on the language. In C and C++, lowercase_with_underscores is a fairly common naming convention. In many other languages, you'd virtually never see an underscore. But at the end of the day, it's really not important. Whether a function is called write_to_log or WriteToLog isn't actually going to make a difference. Someone is going to have to just suck it up and conform to what the team has agreed upon there.

Don't know anything about MVC, I've heard a lot about it though with things like backbone.js. I think it's a way to organize an application. It just confuses me though because by now I've made my own organizational structures.

As with unit tests, never stop learning. You work together with people who know things you don't, and who come from a different background than you do. Learn from each others. There are clearly things you can teach them, but there are also things you don't know, or have never heard of, which they can teach you. That doesn't mean you (or they) are a bad programmer. It means that a good programmer is one who strives to improve, and to learn from others.

Complete OO programming really leaves a bad taste in my mouth

Same here, and I am what you'd call "professionally trained" (a CS degree). People who have been taught programming differ just as much as people who are self-taught. It sounds like you're working with some who really need to learn a few new tricks.

In fact I'm rather scared of the fact that people will eventually be checking out my code. Is this just something normal any programmer goes through or should I really look to change up my techniques?

Both. Of course it's scary to have others look at (and judge) what you've made. But it's also very educational. They can tell you what they'd have done otherwise, or why they'd have done it otherwise. They can help you improve, and they might also learn something themselves. Show them code that solves a problem better than their "preferred" solution would have done, and hopefully they'll go "oh, that's neat. How did you know to do that? What do you call this? I should use this technique myself"

Answer 11

This isn't a full answer, you've already got several good ones. However, there are a couple of points that to me look a bit confused and haven't been addressed.

It's a mixture of several things I do. I tend to blend several programming paradigms together. Like Functional and OO. I lean to the Functional side more than OO, but I see the use of OO when something would make more sense as an abstract entity. Like a game object.

To me it looks like you are confusing declarative vs imperative programming, rather than Functional Vs Object Oriented programming. If you mean that you lean towards declarative programming and away from imperative then that is a good thing. Declarative seeks to remove side effects, which should make your code easier to understand.

Modern programming languages often support declarative programming model. For example, in C#, using Linq results in a declarative style, because you aren't saying how to obtain what you want; you are only saying what you want.

Complete OO programming really leaves a bad taste in my mouth, yet that seems to be what EVERYONE else is strictly using.

Modern languages are often multi-paradigm languages. It's rare that anyone uses a "pure" language. Many Functional languages support objects and side effects. Languages considered Object-oriented often don't impose the constraint that everything is an object.

What do you mean by complete OO? I've never worked on "pure" OO code. Perhaps you can give us some more specifics of what you dislike. An illustration from an open source project might help.

OO programmings gives us many features to support things like: data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance. If I looked at a code base that didn't take advantage of that, it would leave a bad taste in my mouth.

Answer 12

Short answer: yes.

Teaching yourself is almost all good.
Filter with good sense, good advice.

WRT learning professional programming, yes.
What do you have in mind?
Conferences, seminars, certification, a degree?
Each has a cost/benefit.
When the ROI is good, if you have the resources, go for it.

Weigh advice on degrees by considering the source: people with/without them have vested interests.
Talk to a half dozen of each.

Is academia isolated from industry? Often.
Is a degree worthless? Dollar-wise, hard to argue.
Grads almost always make more money, but watch out for college loans.

Knowledge-wise? Maybe.
If you hate school, you won't get more out than you put in.

If you feel like a degree is a worthy goal for you, it probably is.

Dig deeper and find out about the program of study, the costs, the environment. Make sure you have the interest, commitment, time, and resources. You probably went to school for thirteen years, so what is another four? They will be the most expensive, and the main person you will rely on to make them the most valuable is you.

Costs can be pretty scary, but they only tell a part of the story because there are many grants and scholarships for merit, need, and one hundred other reasons.

If you go, pick smart profs and buds.

Answer 13

Second Question - Can I use my own style?

You have two questions.

The first is in your title. Please see my earlier answer.

The second is detailed in about five paragraphs where you characterize how your style differs from professional style with the points listed below:

• 100% self taught.
• Different in technique and organization.
• Blend of functional and object oriented.
• Less complicated.
• Lots of closures.
• Few comments.
• No unit tests.
• Few underscores.
• No MVC.
• No backbone.js.
• No template applications.

Summarized, I think you are asking if it OK that you use the Frank Sinatra approach - "I did it my way." I sense ambivalence as you call other people's code professional, but you are not on board with it. Style is a sticky personal issue, and the debate about what is good code is endless and often a waste of time. Some issues may be easier if your group uses a written coding convention. Please check out:

http://en.wikipedia.org/wiki/Coding_conventions

There is an etiquette to killing someone else's code, and that is another things you should work on with your team. Put your thick skin on and hope they are not too brutal, but whatever you do, don't go to war.

You commented about anxiety about others seeing your code. Get ready because not only will they see it, but they will rewrite it and tell you what is wrong with your style. Your coworkers may be flexible or rigid. Either way, I recommend you not rewrite their code for style or make each point of style a negotiation.

Reasons for having uniform code (and uniform training) are to increase the velocity and productivity of development, and to in someway, institutionalize the learning of best practices. Issues like camelCase or use_underbars can seem trivial and petty, but there are benefits to consistency.

Please be open to unit testing and test driven development. When you are alone, not part of doing projects for pay, it is more like a hobby. Your stuff doesn't need to mesh with what other people are doing. If your code crashes, no big deal. But when you are involved with a team, the code that you write can effect the entire team, particularly if it gets to customers.

Similarly, if your team uses MVC, please learn about it, hopefully from the same sources they reference. Methods of structuring programs can make a huge difference as has been shown by experiment. Again, take the example and leadership from your team.

If your team uses backbone.js, you use it too. Your team is like ducks flying in formation. Lining up together helps them expend less energy, makes them safer, and helps them gets where they are going more effectively. The analogy breaks down if you push it very much, but there are big advantages to using common tools, techniques, and aligning behind the teams decisions.

Answer 14

The advice given is quite useful, but I try to remember that my primary goal is to create 'working software' that is useful to my users. My audience is usually NOT a group of programmers -- they are business people that are willing pay money for an automated solution (Users don't care about OO Methodologies, Frameworks, Unit Tests, code comments, etc. so don't get too hung up on it.)

I've found the ideals of the Agile Manifesto useful in my career (www.agilemanifesto.org)

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Answer 15

I completely relate to this question. I have the exactly the same feelings and a very similar background (but not exactly same). I am supposed to be trained professionally (or rather academically) so I am supposed to know about OO programming etc. Programming wasn't my major topic but I hvae done it. I learnt OO in some of my courses and didn't understand reason d'etre at all. Infact, the only time I understood OO was when I did commercial work and was coerced into it by two great mentors.

I am sure my professor was equally brilliant but you see the real benefit in practice in a commercial environment vs functional programming but you don't have a chance to see it in a course which is designed to run and teach and end within a few months. I haven't had the chance to work on MVC based structure but I am sure it will be the same i.e. I woiuld be able to pick up the concepts working from a book but I will understand its benefit when I see it in use in a commercial environment. And I totally agree with you, why use OO and MVC and any other complex structure if you can solve a problem through a simpler way. My advice is to not be shy of work because it will expose you to situation different and allow you to understand the same things in a different light.

Sure I learnt syntax and concepts in my academic background but it is in commercial world where I started to learn to program.