I taught some senior level courses at the local university.
A Student, by definition, is someone who is still getting their education.
I am assuming a Sr. Developer not to be based on age, but on skillset.
And in particular, "core skillset". Not some 55 year old Cobol programmer now
despite being a very Senior Developer.
There were 2-3 kids in each class who could actually code already. There were 5-7 that were lost.
And the rest of them were actively learning, but I would NEVER allow work on production code. And
this was their last year at the University.
I believe you got caught up in Hyperbole.
But lets get back to your question: Asking "student" questions of a "professional" group.
The VAST majority of us here are NOT students, per se. We may be learning skills, but we are
mostly professionals. And if we stay here at this site for 10+ years, I can promise you that we
are, on average, not students for the majority of the time, despite being in "student/learning" mode.
So, why should the surveys represent the most transient set of us?
BTW, I will ask you one of my day one questions. WITHOUT looking it up. Focusing mostly on the C programming language. Please tell me the difference between for and while statements, and when and why you should use each?
No, I just got fed up by the so-called professionals around my area (within range of 400 km).
difference between for and while statements, and when and why you should use each?
I will try to improvise.
There is no difference, just sugar coating. The main answer is in the hands of Assembly generated, which (I believe) will be same.
For normally leaves the control to "what data has", whereas while leaves the control to what user 2as (or what program has).
For can be helpful in cases where you know where to start and where to end, whereas while is helpful in cases where you just know when to stop (unexpected end possibly).
For has a cleaner syntax (IMO), while requires extra statements that are embedded in for loop's statement.
In the light of what I have said above, use for in cases where you are going to iterate over a collection of available data; contacts, database records, or any already available data structure, whereas while can be helping for the cases where you are still capturing the data; loading the buffers, reading files, getting data from user — enter 'q' to quit etc.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
Excellent answer. The short version is what you said in the end.
Use a FOR loop when you KNOW the start/stop, have a count, etc.
Use a WHILE when its a condition (while !eof, while !null) reading an arbitrary file is a great example.
Why does it matter. Because, like you said, to the compiler, it might be the same.
But the compiler is only 1 of 3 consumers of our source code. And it is the most demanding, so
forget about it. The difference is in what you are communicating about the problem you are solving.
And for me, that is the beginning of a Sr. level developer. They not only get the right answer, they get the answer right. I usually teach the students to solve every problem 3 times. Once to prove you can. Once to get it clean. And the last time to get it right. To remove all excess baloney and make something you are proud to turn in.
Sorry to hear about the people in your area.
I run into it in some places, all the time. People who have 5 years of experience, that REALLY have 1yr of experience 5 times in a row. Imagine telling me you have 3 years of SVN experience, and I ask you about merging. And you tell me you have never done a branch, tag, or merge. My response is that you don't have 3 years of SVN experience. You have 3 years of SVN COMMIT experience, LOL.
My favorite was a guy who hired a new PHP developer. The programmer had 10 years of experience, and was willing to work for $16.00/hr (full time=$32K/yr). I tried to explain to the manager. Only one of those facts should be true. (This is South Florida. Not quite CA or NY, but not cheap either).
Lets just say, it ended badly about 9 months later. Nothing this guy wrote could be trusted. And he was sooo close the last 3 months. LOL.
So, be the best you can be. Help mentor those who want to learn. Avoid those who don't, and find peace in the fact that you will leave a positive impact on those that got to know you!
I am assuming a Sr. Developer not to be based on age, but on skillset.
And that is exactly the point in my other messages. Pity is that there are quite a lot seniors that just got there due to time in the company and not only for merits. And those... those are damm dangerous.
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.
Well, there is the option for "I don't work" so I don't see what the problem is. I also don't see the particular harm in a poll occasionally being directed toward working professionals. There are plenty of other polls regarding development styles and software choices.
Students also code, and most students code better than Sr. Software Engineers, at least in my area.
Hm, I think perhaps the notion of "Senior" is often misconceived. From my understanding, it doesn't solely focus on the length of time an individual has been developing, or even how long they have remained at a single company.
My understanding of a "Senior" developer is that they are not only capable of handling the full development life-cycle, but also being able to direct and guide others, as well as being able to think outside of the box.
I think the difference here (and this is my opinion, I don't have any facts) is that students and post-graduates tend to have a greater understanding of modern development technologies and constructs than those in working roles. When you develop software for a company, unless you're lucky, the majority of the time you're extending an exist product. Introducing new technologies and frameworks isn't always as simple as you would expect.
The problem is that most students (again, my opinion) don't seem to have much idea of what working on existing products and platforms really entails. And while they may have a firmer understanding of newer technologies, and how to write more syntactically correct code, and even perform correct testing, a student cannot measure their own seniority or programming capabilities until they are thrown into development on live products, where they must work alongside other colleagues, ensuring that their changes are backward and forward compatible, and must also utilise the frameworks and technologies available to them (though those used to working on open source projects may have a better understanding.)
That's my two cents anyway. It might be utter crap, but on more than one occasion when I have either: a) hired a new developer; b) moved job and started alongside others, I have seen people try and update dependencies and libraries and bring in new technology, only to have everything break. Being a good developer isn't just about how "good" you can program, or how much knowledge you have, it's also about being able to adjust to how a company or product practises.
Apart from having to relocate on account of family reasons, the only time I've left a job is when I thought I wasn't growing professionally. As long as I'm learning on the job and my skills continue to be kept current, I've felt no reason to leave. Also, I happen to my current company and the work I do.
I agree with you. Unfortunately, it does not always work out that way. Here, in the United States, companies expand and contract, appear and disappear with alarming frequency. My resume is littered with companies that have merged into others, been downsized due to a dearth of new contracts, been spun off from a larger corporation without the resources to succeed, gone bankrupt and other ignoble fates.
The other "job killer" for me is being forced into management. I became a programmer because I like to play with computers. Every time I am forced into management, I find more and more of my time is tied up in paperwork, meetings and personnel activities, leaving me precious little time to play with computers. Being a manager is a job I do not like, with too much stress and too little reward.
Actually I've worked most of my life in the US. I only moved to Canada ten years ago. I guess I've been lucky enough to work at established organizations (early in my career) and successful startups since the 2000s (although I've experienced a couple of crash and burns, too).
Jalapeno Bob wrote:
being forced into management
Yes, that would it do it for me too. I've always chosen to stay technical. I think companies that offer a purely technical sofware engineering career path do exist, but are usually small to medium size outfits. I don't think I would ever work for a large organization again.
I used to stay at a company 2 - 4 years and then I joined a company and "settled" in and got "comfortable". At around 14 years, the company decided they needed to move everything offshore. I watched all my co-workers go before me until at year 16, I got the tap on my shoulder. It was a good run while I was there. While we had somewhat kept up with current technologies, my skill set was still a little "dated". I was still able to get another job quickly, but I have had to play "catch up" very quickly. Had I moved on a little more often, would my skill set have advanced? Hard to say, but I think the opportunities would have been there more often than by staying at a company long term.
My first full time employment was almost 13 years; that ended due to corporate restructuring.
From there, I changed countries (Canada to U.S.A), but worked with the same technology set (VAX/VMS, FORTran, FMS). Stayed there for almost 13 years before switching to my current position - that is coming up on 5 years.
Now, I focus on a single technology base (OSISoft PI system) instead of being a developer, analyst, de facto DBA, troubleshoot everything person.
As long as I'm happy with what I'm doing, it provides for me and my family, I have no plans to change.
I have been on the current job since May 19, 1997. This has been the first and only full time job I have had. I graduated from the University of Pittsburgh in December of 1996. At this point I hope to stay an additional 10 to 11 more years and then retire (or move on to some type of consulting work where I can reduce my hours).
I usually prefer to stay at my company until my 401k is vested by the company 100% and until the project that I'm working on ends (3-5 years usually). Having said that, I past that milestone a while back and have been with this company for just over 7 years (longest ever).
So - I picked a preference - but that doesn't mean the world offered that road for me in the past.
Prior to "here", I was in place nine years. (Their experience, after "letting me go", allowed me to relish some proper schadenfreude). Here (both as contractor and employee) now amounts to about fifteen years.
When they get tired of me "here", I'll go - but they put food on my table (and that of many others) for all these years, through good times and bad. There are greener pastures in terms of money, but they remember that employees (even in the most menial positions) are people. Nice.
No one with the right mind signs a contract, with some set up about how many years (months) it will last...And no one with the right mind leaves a job just because the time is up!
It depends mostly on the human environment, on the challenges and personal preferences of that time...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Last Visit: 31-Dec-99 18:00 Last Update: 27-Sep-23 14:46