Identify other problems and challenges that software engineering is likely to face in the 21st century? In the future, software engineers will be forced to make morerobust software programs that. In this paper, I discuss two types of challenges facing software engineers as they develop software for scientists. The first type is those challenges that arise.
![Management Management](http://slideplayer.com/6402298/22/images/61/What+are+the+key+challenges+facing+software+engineering.jpg)
I'll separate the challenges that a software engineer faces into technical and operational. Technical challenges are what you normally associate with the core coding aspect of software development. It's learning the languages, the frameworks, the systems and the algorithms.
It's dealing with writing quality, maintainable code that can scale to multiple systems that can serve millions of users. It's finding and fixing logical errors, debugging some esoteric minute bug in the code.
Operational challenges are less unique to software development and thus less mentioned but equally if not more difficult to handle. Dealing with management, career advancement and recognition, collaboration with other engineers as well as designers and product managers, and continuous education of both technical and business parts of an organization are all issues that software developers face.
As a matter of fact, the emphasis on the pure technical challenges above downplay these operational challenges. Beyond those mentioned, I would add: -dealing with colleagues. The tech world is statistically male, white, young, full of intelligent, opinionated people who make up in technical proficiency what they lack in people skills. It tends to breed a type of people whose way of thinking and if relating to others can sometimes stray close to the boundary of autistic spectrum. Add that the fact that everyone is under pressure, and it's easy for things to get problematic. There's a huge amount of misplaced pride devs will put in their solutions, and very often the line between searching for the best architecture and having an ego driven pissing contest of 'my way's better'.
A corollary of that pride is that a fair amount if developers don't feel well with code review or architectural steer, and generally have trouble distinguishing between feedback and criticism. work life balance.
The reason (good) devs are so emotionally invested in their work is that they dig it. Most are people who enjoy problem solving for fun - okay, it's not a walk in the park every day, but you're forever lucky to be paid to do something you generally enjoy. Combine this with the archetypal culture of tech companies, which strive to make the office a comfortable, fun environment, with game free drinks/food, places to crash and chillax. Then combine this with a demanding job with tight deadlines.
You end up with people for whom life is work, who'll spend an inordinate amount if their waking time in the office, keep on working at home, etc. That's the way it is - the industry needs to milk as many hours of dev out of young techies when they're in their 20s, have not much else to do beyond work, and are willing to sink in it very deep - because soon they'll get other priorities, maybe a a familily, and they won't want to be submitted to the crunch.
It can, and will, drive you mental if you're not careful. The technical challenges are not really problems, they are just challenges and most often fun to deal with. The satisfaction gained by solving a critical problem is immense and long lasting. Th real problematic challenges are the non-technical ones. A stupid manager can really make you feel miserable, and the way you deal with this problem is not easy. In extreme cases, the only solution is simply leaving the job.
I have seem almost a whole team leaving a company because of a bad manager. Unrealistic expectations and over-ambitious deadlines are very common, and can really cause stress. Implementation of Agile has actually helped developers in this respect giving more power to the dev teams in terms of deadlines and targets, but the problems have not fully gone away. Let’s talk about four career stages, since the challenges evolve as one’s career progresses. The four career stages are Apprentice, Journeyman, Leader, and Manager. Not every career touches all of these phases, nor does one necessarily traverse them in the order I’ve listed them, but they are quite common.
Apprentice is the entry-level phase of a career. It is typically the first three to five years of professional activity. In this phase the software engineer is learning the important artifacts of his practice world: the tool chain used by the team, the code base of the product that the team works on, the development process practiced by the team, and the product produced by the team.
The challenges in this phase are just mastering all of the detail. The apprentice will be given tasks by a more senior member of the team and will be coached in their execution. The tasks will be selected to cause the apprentice to explore the tool space, the code space, and the major execution phases (code, build, test, push to production, system monitoring, and incident response). In the Journeyman phase the engineer will be given larger and larger components of the product to design and implement. In this phase the engineer will be expected to demonstrate his ability to write a design document, to explain analytically what design choices he made, to design important components and architectural subsystems of the product. As the journeyman progresses she will be given the opportunity to direct the activity of one or more apprentices.
In this preliminary test of the engineer’s leadership abilities her behavior will be examined subtly but carefully to ensure that her treatment of her more junior colleagues is mature and professional. By the end of the journeyman phase the engineer will enter the Leader phase. This is sometimes called the TL (Tech Lead) phase or the junior manager phase. In this phase the engineer is given responsibility for the overall design and implementation of an entire product or major component and entrusted with a team of more junior engineers, typically about half journeymen and half apprentices.
Success in this phase depends both on the timely delivery of a working product and on clear evidence that the engineers on the team have demonstrated healthy development along the tracks of their own careers. After a number of successively larger leadership engagements that have shown strong signs that the engineer is a capable architect, designer, builder, and operator and has demonstrated the ability to attract, retain, and develop valuable talent, the engineer may enter the Manager phase. In this phase the engineer looks after a portfolio of interrelated products and a set of teams, each headed by a leader.
At each stage of the career the engineer is concerned with the software development life cycle: requirements, architecture and design, construction, testing, deployment, and operation. The nature of the engineer’s engagement with that lifecycle deepens across the career. As an apprentice he is learning about the life cycle. As a journeyman he is caring for and feeding the life cycle. As a leader he is optimizing and enhancing the life cycle. And finally, as a leader he is teaching the next generation all of the life cycle skills.