|
This whole Jr/Sr level of developer has always bothered me a bit.
It is supposed to imply experience AND ability.
For example, I am a VERY GOOD problem solver. I solve the problem first, then write the code.
I was trained as a "Programmer/Analyst" and I appreciate the Analyst part, which we have lost.
So, while I am very Sr with problem solving, with .Net I am very Junior/Inexperienced.
Although I have written about 500,000 lines of C code in my life, how do I apply for a Sr. Level C# position? In a one many shop, taking something over, I would be less effective than on a team with one really talented C# person to chop my learning curve.
==
So back to your question... The challenge is that we need to stay in touch with the schools, etc. if we want to find young talent. Coding schools, maybe, to find "fresh" talent (someone like me learning a new skill), and we have to separate skills in development from ability with a language.
Just my 2 cents.
|
|
|
|
|
Yes!!! Connection/stay in touch with other organizations are very vital.
Bryian Tan
|
|
|
|
|
25 years ago, I was teaching programming at a tech college for six years. One kind of student was universally "hated" by the lecturers: Those who got their first PC, with software development tools, at age 10 and after having played around with it for 8 years come to college "knowing everything" about programming. To unlearn them all the bad habits was a nightmare. (Once a student handed in to me a homework assginment in two versions: First, a reasonably good solution, headed by "This is how the professor forces us to program it:", then, as a huge comment block, headed by "This is how a real programmer would do it:" and the dirtiest, messiest code you could imagine.
Nowadays, I work with a fair share of junior programmers, more or less right out of college (but all with an academic education), experiencing a deja vu. Those still glowing from the college oven know how everything should be done and organized and structured, attempting to turn the entire shop upside down. I mean, the problem isn't the lack of experience, but they believe they have it. Or rather, that their academic education is a lot more worth than any level of experience. None of them considers themselves junior developers, but rather glorious messengers who are there to enlighten the dark industrial world with the shining light from the new acacemic ideas.
Sure, at least 90% of our developers have university level education. We probably behaved the same way in our first year or two. We were probably just as self confident as today's youngsters are.
I guess that part of your problem is to make people realize that they are juinors. Admit that they do not know everything, even if they have picked up the latest crop of academic ideas. They know to sell themselves by "I know how to do it", not by "I am willing to learn how to do it the right way", which is far more true for a junior developer. But it doesn't sell.
|
|
|
|
|
I think here another challenge, sometimes it depend on the pay scale too. If the position is paying xyz dollar, let say per industry standard, xyz dollar range is for Junior category. We can't advertise the job as "Mid-level or Senior" category position with xyz dollar pay rate.
Bryian Tan
|
|
|
|
|
A whole weekend? That's quite a while to be searching and not finding anyone.
Anyway, junior [insert tech here] developers are not found; they are made. You're looking for graduates or people with logical thought processes, good attention to detail and a hands on "can do" attitude.
|
|
|
|
|
|
There's no such thing as a "junior" anymore. All of the NCGs are working on Python, Javascript and other stuff. C# and .NET in general doesn't exist to them.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
In my experience, this shortage is due to the HOT or NOT view of programming. Dot.Net is not seen as sexy to the incoming crop of CS.
Swift - Sexy
C# / Xamarin - Not sexy
Node/Angular - Sexy
VB.NET - Not sexy...and worse - taught in pseudo-CS courses as "programming"
PHP - Not Sexy
ASP.NET - Not Sexy
Java - Not Sexy
Ruby on Rails - Used to be Sexy, but not anymore
SQL Server = Not Sexy
MongoDB - Sexy
Postgres - Sexy
MySQL - Not Sexy
C - Nox Sexy
In general
Microsoft Backed - Less Sexy
Open Source - More Sexy
We have a rich code base in VB.NET, but have had to teach incoming employees the language and framework. Thankfully, it is super quick to get up to speed with. Which is probably why the only people who get VB.NET or C# experience are the CS-Lite degrees (Computer Engineering, etc.)
I see new grads with Java,Erlang, Scala, Python, and Ruby "experience", of which we only commercially use Ruby. Java, which is taught almost exclusively at schools around San Diego, is something we don't even use.
|
|
|
|
|
All the juniors from my college that I met are crazy about bootstrap and angular and php. 
|
|
|
|
|
I graduated four years ago from college -- and all I have been able to get are interviews for 5+ years to Senior Level roles. Nobody works with people anymore to train, Companies don't want American workers to train they all outsource Director and Sr. level roles from India, Russia, Pakistan, then that manager hires young people from his country.... Seen it for years. There is NO shortage of Jr. roles just a shortage of jobs because they are all being booked by foreign workers. Government, Silicon Valley, Microsoft, it's everywhere!!! 
|
|
|
|
|
The general thing is to hire a mid-level dev on a junior devs salary - Seems to work when people are struggling to find jobs
-= Reelix =-
|
|
|
|
|
Do you reference other projects or do you reference the assemblies from other projects?
I've been on a lot of teams and I've seen it done both ways? What's your take on the right way to reference other code?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
If they are all in the same solution then I reference the assembly(DLL) as that is what is suggested in VS2015.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Not sure I agree, but maybe I don't understand what you mean.
|
|
|
|
|
Usually I reference the project so I can debug into it. Once you've made a release build and deployed it it doesn't matter how you set it up in the VS.
What I have run into (many times) is accidently referencing a DLL that's installed in the GAC and then wondering why my changes aren't taking effect. 
|
|
|
|
|
I'm with PIEBALD on this one, reference the project so you can debug into it.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
+1 reference to the project
|
|
|
|
|
Why would I want to reference just the dll if I have access to the project?
I'm only seeing limitations.
|
|
|
|
|
suggest it for future polls? Poll Suggestion Page[^]
You will probably get more people answering than posting here
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I thought you could just create a poll. I'm sure I did, once.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Maybe it was like that... then
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
"There were eight-teen of us livin' in that septic tank!"
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Reference other projects because the referenced dll will reflect the changes made from other projects automatically when rebuilding the solution. Unless if you want other developers not to edit the code directly from other projects(core project or business logic) referencing the assembly is the way to go. 
|
|
|
|
|
It depends.
If the "other project" is a utility set that is shared by other solutions, then generally I would reference the assembly.
If it's going to be changed as the current solution evolves, then I reference the project so I can debug through.
My general rule is simple: if it's external to the solution then I reference the assembly - and "upgrade" to referencing the project if it becomes necessary. That way, my changes are not risking other solutions which may depend on something working the way it does now.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
