Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Comments
The Reality Of Freshly Minted Software Engineers
Newest First  |  Oldest First  |  Threaded View
Becca Lipman
50%
50%
Becca Lipman,
User Rank: Apprentice
11/25/2013 | 9:44:03 PM
re: The Reality Of Freshly Minted Software Engineers
Excellent points, I see the same frustrations coming from the
software engineers who start at new companies, desperately trying to
reshape their thinking for their new role. The same can be said for other professions.

It's hard to knock
universities, they teach the skills they can in a relatively short
period. Perhaps they need more time, extra courses, or a mandatory
internship for the students to learn this group-think and refactoring.
IMO, too many group projects run the risk of pigeonholing skill sets when
students get comfortable taking on the same aspect of the project again and again.
tarnold282
50%
50%
tarnold282,
User Rank: Apprentice
10/21/2013 | 6:15:01 PM
re: The Reality Of Freshly Minted Software Engineers
It's not only newly-graduated people - I've found that it also applies to ANYONE who writes software, but not for "real products". In particular, I've seen this a lot from people who work in Research organizations - corporate ones, not academics. Like the student projects you describe, they tend to write everything from scratch without needing to consider things like maintainability or figuring out someone else's old code.
BrianY331
50%
50%
BrianY331,
User Rank: Strategist
10/17/2013 | 7:05:28 PM
re: The Reality Of Freshly Minted Software Engineers
Great article. I think there is an additional factor regarding the mile-wide gulf separating academia from the business world is that there is very little communication or similarity between what happens in the business world and what academia thinks goes on there. I find that vanishingly few computer science professors have ever actually worked in the industry, and many (most?) have never even met anybody who has. Their world of academic publications, tenure, and focus on mathematical theory rarely has anything at all to do with the actual practice of developing software. I have met many of them who believe that the papers they publish in ACM journals are eagerly being read by practicing engineers and used to build systems in the real world. While you can point to a tiny number of examples of this happening in a few areas (like graphics for example) it is uncommon even there and entirely absent everywhere else. While medical schools have active connections to real doctors and real hospitals, new CS grads have likely never even talked to an actual software engineer and may never have even talked to someone who has.

Ponder this, if you could hire one of two people for the same amount of money and one was a fresh CS grad and the other was someone with no formal education in software development but with 20 years of hands-on experience you would clearly hire the second guy, right? What if he only had ten? Likely you would still hire the experienced guy, right? What about 5 years? or 2 years? Comparing someone with a 4 year degree with someone with 4 years of hands on experience, I think I would still rather take the guy with 4 years of experience, all other things being equal. If that's the case, a 4 year degree is a waste of time regarding one's software development skills. It might well do you some good to read Shakespeare, learn calculus, and learn a second language, but when it comes to software development skills? It's not a good investment in time and money for most people.
Don Gray
50%
50%
Don Gray,
User Rank: Apprentice
10/15/2013 | 7:19:23 PM
re: The Reality Of Freshly Minted Software Engineers
Gunter,

Excellent article and I believe you have hit the nail on the head!

I am on an advisory board for my alma mater and the first few meetings I attended I tried to use my position to highlight these exact issues. I proposed that the university adopt a multi-year project approach creating 3 credit 100,200,300,and 400 level classes that would revolve around a 2 semester project that was designed by the Year 4 students.

Year 1 students would act as the Quality Assurance team, Year 2 students the Technical Analysts writing the specifications, Year 3 as the Infrastructure & Development team, and Year 4 as the Architects and Project Managers.

In my mind such a program would serve several purposes:

1) Create interaction amongst the students in different years allowing mutual learning and teaching large group project dynamics and fundamentals
2) Force every student through the 4 year program to see the many sides of a software project and the different roles involved
3) Create "ready-to-hit-the-ground-running" graduates that could actually be of some use

I was told that such a program was not feasible and unrealistic, even more strongly I was instructed that this was university not a trade school, the mission was to teach the fundamentals and theory not the application of it.

I should have known better, I tried 20ish years ago to get a 1 credit course approved to teach JCL, since the FIRST thing I was trained on when leaving college was JCL!

I think by adding in your concept of modifying existing code, you could have the Year 4 project by enhancements to the prior years project, giving the teams a 4 year exposure to the same codebase.


Major Brazilian Bank Tests Homomorphic Encryption on Financial Data
Kelly Sheridan, Staff Editor, Dark Reading,  1/10/2020
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Microsoft Patches Windows Vuln Discovered by the NSA
Kelly Sheridan, Staff Editor, Dark Reading,  1/14/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20003
PUBLISHED: 2020-01-17
Feldtech easescreen Crystal 9.0 Web-Services 9.0.1.16265 allows Stored XSS via the Debug-Log and Display-Log components. This could be exploited when an attacker sends an crafted string for FTP authentication.
CVE-2019-3686
PUBLISHED: 2020-01-17
openQA before commit c172e8883d8f32fced5e02f9b6faaacc913df27b was vulnerable to XSS in the distri and version parameter. This was reported through the bug bounty program of Offensive Security
CVE-2019-3683
PUBLISHED: 2020-01-17
The keystone-json-assignment package in SUSE Openstack Cloud 8 before commit d7888c75505465490250c00cc0ef4bb1af662f9f every user listed in the /etc/keystone/user-project-map.json was assigned full "member" role access to every project. This allowed these users to access, modify, create and...
CVE-2019-3682
PUBLISHED: 2020-01-17
The docker-kubic package in SUSE CaaS Platform 3.0 before 17.09.1_ce-7.6.1 provided access to an insecure API locally on the Kubernetes master node.
CVE-2019-17361
PUBLISHED: 2020-01-17
In SaltStack Salt through 2019.2.0, the salt-api NEST API with the ssh client enabled is vulnerable to command injection. This allows an unauthenticated attacker with network access to the API endpoint to execute arbitrary code on the salt-api host.