Iyfjky

Question

I'm a master student in CS in a German Uni and soon I will graduate and start looking for jobs. I'm a very experienced java programmer (I believe). I built some projects for personal use and uni course. Now when I started to look for jobs people over the internet are telling me that experience that I got from my personal and uni projects don't count as professional experience. That actually shocked me and made me very curious about how the code would be different between a junior and a professional java developer who have 3 years of experience for example in the industry.

My questions:

1- Can you give me some examples, using java code, to show the difference between a junior and professional java developer?

2- Are there other factors that make someone be junior/experienced other than code?!

Did you ever do an internship or other professional working experience in your life? — Dec 3 '14 at 16:28
But it is not just a java thing. You also do not yet have professional experience and will typically start in what is called a junior position. If you are a good coder and worker you will rise through the ranks. — Dec 3 '14 at 16:38
@JackTwain It may be different in other countries, but in the US, university doesn't teach you how to develop real-world, business critical applications. They introduce you to the fundamentals but often fail to teach even some of the more basic aspects of professional development like managing multiple environments (development, staging, production), code reviews, source control, working as a team for more than a few weeks, office politics, shifting priorities, scope creep, etc. The real world is a very different place from university. — Dec 3 '14 at 19:11
Even the coding part is very different when you are making a change in a million line code-base and making sure you don't break anything (including adding bugs, violating style guidelines, subverting the architecture...) and that future developers will understand it, and putting in a 12 line comment explaining who made what decision that led to the incorrect-at-first-glance change you just made. — Dec 3 '14 at 21:49
I'm a developer with a few years of experience now. To be entirely honest, most of what I learned in college ended up being pretty dang useless. I've actually had to unlearn quite a number of the habits and practices and modes of thinking I picked up in school and on personal projects. So for me, the difference was enormous. It was shocking to me how wrong I was. — Dec 4 '14 at 0:11

score 56 · Accepted Answer · 2014-12-04 00:03:25Z

In general, 'junior' means less experience. This is not strictly related to any particular skill. As phyrfox put it,

Years of experience doesn't translate into quality of code, but usually does affect other non-code skills, such as teamwork, working under pressure, getting exact business requirements implemented, etc.

For example, depending upon the particular job...

reading other people's code

learning the product's design - sometimes when there is no documentation, docs are wrong, and/or the experts have left the company

As Patricia Shanahan mentions in the comments, focusing on the things you really need to learn to be productive with the code base, rather than trying to learn everything, which is impractical.

debugging other people's code

breaking a product in a critical and hard to foresee way

working with QA to get your code tested

following company policy in general, or this company's policy, specifically

following a software development lifecycle

following someone else's design

making the case to a team about the 'right' way to implement something

doing it the other guy's way when their approach wins out

interacting with customers

interacting with customer support

accepting decisions that 'make no sense' because of factors you just don't understand

recognizing when something really is harmful, investigating to understand why the decision was made, and finding a more efficient and cost effective way of doing it (or realizing the decision is right)

working on a team with varying levels of skill

mentoring others

working in the particular problem space of the application

working in a product as big as the one you'd be working on. As HLGEM points out in the comments, professional applications are huge - much, much larger than what you work on at school. They are commonly tens of thousands of lines in moderately sized projects, and can be millions of lines in larger projects.

effectively communicating with non-technological folks

working in a fishbowl/cubicle/office

understanding team dynamics

understanding and navigating company politics

understanding the company's goals and how your job affects those goals

There are many more. You may have amazing coding skills, but are all these skills really all that well practiced?

I would add that business projects are often much more complex due to massive amounts of specialized reuirements (that accumulate over time) than course work or personol projects. Our code base is over 15 years old and contains many thousands of lines of code, it accesses a database with hundreds of tables and millions of records. It has more working parts than anyone could actually know written in mulitple languages including some older stuff in VB6 that was never replaced because it works. — Dec 3 '14 at 16:57
In my experience mentoring new computer science graduates, one of the biggest hurdles can be working on a program without first reading and understanding the whole program. — Dec 3 '14 at 19:50
Years of experience doesn't translate into quality of code, but usually does affect other non-code skills, such as teamwork, working under pressure, getting exact business requirements implemented, etc. — Dec 3 '14 at 20:32
You shouldn't need to look outside the part of the code you're working on to understand what affects your changes might have on the rest of the program. But all too often, programs written by so-called "professionals" are huge blobs of interdependent global state. — Dec 4 '14 at 3:30
And even if the programs are actually well designed, they may not be designed the way you would, and "feel" as if they make no sense. Another hard thing to learn is to make your changes reflect the same general design that the existing code does, regardless of how you would design it if it were new. — Dec 4 '14 at 10:13

score 14 · Answer 2 · 2014-12-22 04:39:07Z

The other answers are correct, but you asked specifically about the code.

It seems like every 5-10 years I think I fully understand every aspect of coding and yet find another revolution. Anyone can solve any problem with code if they are motivated enough--I've seen non programmers create amazing solutions.

At this point I belive the priamry difference is how much can be added to such a codebase before it fails and has to be re-written, and how much time/effort/money do you have to spend maintaining it.

As you go up in compentency, those costs go down quite a bit. It's difficult to point out at first. Imagine the difference between someone who plays basketball and can beat everyone on his block and a pro basketball player--even though they may look like they are doing everything the same way, you won't find the neighborhood guy coming anywhere near the pro.

It takes more than just time, it takes experience spending months finding really stupid bugs, years of refactoring your own code to improve it, exposure to concepts that you might not encounter for years as well as the knowledge to KNOW that a new pattern you just concieved of won't hose the entire system.

You may need to know a million little things. Maybe some examples just related to coding:

Obscure patterns/tools that fit specific scenarios like a state table or a quad tree for 2 examples (out of thousands)--and just what problems would be simplified by their use

The workings of linked lists, arrays, and hashes to understand perfomrance implications.

Identifying redundancies in code that may not look at all similar.

How to identify code that is hard for someone who understands less than you to understand and make it understandable at a glance.

You will need the will to refactor code that needs it even in the face of a deadline, and the knowledge to know the one time to make an exception... for now.

a million other little things

Specific examples are hard to give, there are different styles and opinions. Mainly I consider a good programmer someone who understands that he's programming for the next person to read, not to make the machine run, and codes appropriately.

This. As a professional, you're not writing code for today, you're writing code next year (or next decade). It takes experience to write code that minimizes the cost of change down the line. The longer you work at it, the better you'll get (presumably). — Dec 4 '14 at 0:16
Good answer. I would just add that you also need to learn when to let go of a given piece of code. This can be very hard. — Dec 4 '14 at 8:21

Roger 22115 · Answer 3 · 2014-12-03 16:38:25Z

Simply having the ability to write code doesn't make you a professional programmer. It merely means you can write code. Writing small programs for yourself or as part of your coursework is not professional-level work. By definition, a professional is paid for their work. It is their profession. It has nothing to do with the difference in the code, but in the more intangible experience that comes from working for a company in a professional environment.

How do you work under pressure or deadlines? How do you work with other people, not only coworkers and bosses, but also end users and clients? How do you handle working on projects with massive codebases? These are things that a potential employer is going to be looking for when judging your experience level, not just how well you can code.

Education can give you some of the tools to become a professional programmer, but it is by no means a substitute for working for a company. There is nothing wrong with being an entry-level junior developer -- we all had to start there at some point. But don't confuse education with experience.

"But don't confuse education with experience" sums it up very nicely. Also, the difference in coding skill isn't shown in a single method or function. It's show when you have to work through an entire stack like Symfony where you not only code PHP, but create templates in Twig, configs in YAML, tests in Behat and PHPUnit, manage dependencies with Composer, managing versions with Git etc. — Dec 4 '14 at 12:32

Communityâ™¦ 1 · Answer 4 · 2017-04-12 07:31:57Z

I can't speak to your point 1 (which may be more on-topic at programmers.SE). But I'll happily discuss your point 2.

Yes, there are lots of things beside coding that distinguish a junior from a senior developer. Just a few examples off the top of my head:

Much of a developer's time is not spent on hacking. You will review requirement documents (or even craft your own), write story and other documents, design (and code) tests, and so forth. Activities like these can take up 90% of your time, compared to 10% doing actual coding. You may or may not have learned this at university, but if you did, you don't mention it in your question.

Unless you work in a very small company, a developer will likely work in a team, which can be a smallish scrum team, or part of a large team spread over multiple continents. In such an environment, you need to understand processes (distributed development, code repositories etc.), and you need to understand people and be able to work with them. This is typically something you don't learn at university. Doing pair programming with someone else every day (because that is how knowledge is spread around) is something else than doing a project with the same one or two co-students.

Even the hacking part will differ between the university and the workplace. For instance, at some point in your career, you will be asked to fix a bug someone else introduced in uncommented five-year-old spaghetti code. I assume you haven't seen much like this at university, where you will likely not need to maintain old code created by other people. Senior developers have already been confronted with this and dealt with it.

I disagree with 10% "actual coding time;" we have a remote development team and we are about 20% meetings, 10% housekeeping, 40% unit testing and QA, and 30% production code, spread across tens of thousands of lines of code spanning many years and developers. However, I do agree that Scrum is something no school will really teach, that's hands-on experience. +1 for the bit about debugging, which is more important than being able to write code in many cases. — Dec 4 '14 at 8:39
@phyrfox: I may have exaggerated just a tiny bit on the 10% actual coding part... — Dec 4 '14 at 8:59
@phyrfox: He wrote up to 90% and that's not an exaggeration at all. A friend of mine (who worked in a huge international corporation on a security-critical firmware) was asked once over a beer: what IDE they're using to write code? He hesitated for a long while and finally came to an answer: "MS Word, mostly". Every code change had to be documented, explained, reviewed and accepted by a dozen of people. Bureaucracy sometimes can be that huge - and not without a reason. — Dec 4 '14 at 11:12
Yep, I once worked on a massive aerospace/satellite program. I got assigned a bug, and identified a fix within minutes of looking at the relevant source code (a really, really obvious one line code change). Layers of testing, peer review, various levels of management approvals, etc. Almost a month before that change made it into the code base, even with me actively shepherding my fix through the process (i.e., me being a pest). — Dec 4 '14 at 17:12

Dunk 1,10278 · Answer 5 · 2014-12-03 22:47:06Z

While other answers seem to be giving lists of skills that are needed to be considered to be at a "more experienced" level, I think the difference is far simpler.

It all boils down to how much oversight and direction you need and how does that scale.

I'll use sub-product to try and keep this from being software specific, but think of a sub-product as a module.

New grads tend to require lots of oversight/direction. They need to be taught the details of specifically how things are done at this company. They tend to be told exactly what they need to do. They tend to work on well defined pieces of a sub-product.

Slightly more experienced people but still junior might be given entire sub-products that are well defined and done under the guidance of a more senior person.

As you get a little more senior then you are given responsibility for defining the exact details of a sub-product as defined with minimal details by more senior people.

More senior and you get people assigned to help you with your larger sub-product(s).

More senior and you start to get involved in identifying all the various sub-products from some specification already defined.

More senior and you are helping create that specification from some vaguely defined customer needs.

More senior and you are actively looking for customer needs that will bring money into the company. In other words, you are defining your work assignments.

In general, it boils down to the expectation that the more senior you rise, the less guidance you need, the bigger products you are able to successfully complete and more people that you are directing.

So you may be a great "whatever your specialty" but you are still going to have a huge learning curve on how to do things the "company-way". Thus, a lot of oversight. You'll also need to prove yourself before you get out of close scrutiny. Thus, a lot of oversight. You'll learn that techniques and practices that worked great for smallish projects just don't scale well once things get bigger. Thus, a bigger learning curve than you might think. So you'll have a fair amount of do-overs, making you less efficient than someone more experienced. Even if you are a great "whatever your specialty" for a college student, if you haven't spent 8-9 hours a day practicing and applying those skills for a few years then you are not nearly as good as you think you are, no matter how smart you might be.

More specifically to software, you can't give a code-sample and show what the differences would be because it's about the entire system and not just the code snippets. It might be better to point out what is likely to occur if a new grad/junior developer is not given the proper oversight. The 2 most common problems I've seen are 1) They write absolutely terrific code but it solves the wrong problem. 2) They come up with a design and code that they feel is much better than how they were told it needs to be; the problem is that it doesn't work with the rest of the system so it can't be used.

And how much oversight and direction you can offer to others. The highest-ranked programmers are the ones who spend most of their time designing program architecture that will then be distributed to others to implement... their "programming language" is largely abstractions and ideas and designs, and their "compiler" is the development team assigned to work with them. So "professional Java programmer" isn't that high a status; "team leader" is a step up, and "system architect" a step up from that, and so on. — Dec 4 '14 at 2:41
"They need to be taught the details of specifically how things are done at this company." - but that doesn't apply exclusively to "new grads", but to anyone new at "this company". — Dec 4 '14 at 12:11
"More senior and you are actively looking for customer needs that will bring money into the company." This depends very much on the company structure. Especially in a large-ish company, you can easily be working with whole departments whose sole purpose is to take care of the requirement gathering and formalizing. That doesn't necessarily mean they are senior to you on the corporate ladder, it only means that it is their job and they are on a different ladder within the company. — Dec 5 '14 at 14:47
@keshlam:I agree. There's much more I could have written, especially with regards to "leading/directing others" but I was trying to be a bit more focused on what I thought the OP was asking in that what makes someone more senior than others with regards to the nuts and bolts of the job. — Dec 5 '14 at 20:58
@Mapper:It is true that everyone has to be taught how things are done at this company but I was thinking more to overall process and not specifics of tools used. Most senior people that a company would hire probably already have a similar background with regards to process; so teaching tools and quirks should be relatively quick and not so time consuming and "selling" the process and why following it is important also shouldn't be time consuming. — Dec 5 '14 at 21:03

Paddy 36216 · Answer 6 · 2014-12-04 11:20:48Z

I think one of the major differences between a junior and more experienced developer is often this:

I'm a very experienced java programmer (I believe).

I've been doing this job for around 15 years and what I still wouldn't regard myself as 'a very experienced programmer', partly because they keep changing what we work with!

Without wanting to sound trite, I've worked with a lot of junior programmers who thought that they knew everything (they didn't *) and it can take a bit of a step in mindset to realise that there is always more to learn, and more importantly, you may also need to learn to do things in the way that your employer desires, rather than just what you think is best.

'* Just to say, have also worked with a number of very good junior developers...

The Merry Misanthrope 28619 · Answer 7 · 2014-12-04 03:47:19Z

I think the biggest difference between junior and senior developers (or senior developers who have learned something from their experience vs. the many who have not) is the intuitive ease with which they identify and apply the correct design patterns and industry best practices. When it comes to Java code, consider the highly regarded book Effective Java. A good developer will have read that book or something like it, and practiced what it teaches until it's second nature. On the other hand, I've seen "professionals" with CS degrees churn out mountains of garbage that violate every single one of the software design principles in that book.

As others have noted, there's more to being a professional developer than coding. A lot of it is office politics and trying to find the business case for doing things the right way. I often find myself fighting for strategies that would pay off on time scales of months. Do we want to spend a year doing something right, or do we want to aim for cranking out a pile of shit in three months, have it actually take nine months, and then spend five years trying to fix it, hemorrhaging customers the whole time? I'll never understand why suits always insist on the latter...

how many years experience do you have? Also do you have a CS degree? — Dec 4 '14 at 13:20
I have about about five years professional experience and fifteen years personal experience. I started on a CS degree several years ago, but by then it was too far beneath me to be worth my time. If I aspired to work for other people forever, finishing it would probably have paid off in the form of a higher salary, if nothing else. But I don't. — Dec 4 '14 at 19:08

score 56 · Accepted Answer · 2014-12-04 00:03:25Z