BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts The State of Software Engineering from an Academic Perspective

The State of Software Engineering from an Academic Perspective

In this podcast Shane Hastie, Lead Editor for Culture & Methods spoke to Martin Kropp and Craig Anslow about the current state of software engineering from an academic perspective.

Key Takeaways

  • The current state of software engineering includes the use of AI for software development and the focus on DevOps and security.
  • Automation is a key trend, with a focus on automating processes and improving efficiency, but you can’t automate without first solving the people and process issues.  if you don't have good processes and teamwork, your project is doomed for failure.
  • Diversity and inclusion are important topics in the software engineering space.
  • Remote work is becoming more prevalent in software engineering, and organizations need to adapt to support remote workers.
  • The shift from a project focus to a product focus requires long-term planning and a focus on quality assurance from the beginning.

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, we're sitting down, in person for a change, in sunny Otaki in New Zealand.

We're going to take a look at the academic perspective on software engineering. I'm joined by Martin Kropp and Craig Anslow, and I'll ask the two of them to introduce themselves.

Introductions [00:44]

Martin Kropp: I'm Martin Kropp. I'm a professor of software engineering from Northwestern University of Switzerland, which is situated close to Zurich. I'm spending currently my sabbatical here with Craig Anslow at the Victoria University of Wellington. I'm doing mainly research in Agile methodologies, improve the way we develop software, and hopefully making it even more efficient in the future.

Shane Hastie: And Craig?

Craig Anslow: Good day, kia ora. I'm Craig Anslow, a senior lecturer at Victoria University of Wellington, Te Herenga Waka. That's in New Zealand. I'm a senior lecturer in software engineering, and I've been doing the role for about seven years. First exposed to Agile processes 20-plus years ago in my undergraduate studies, and now I've been teaching Agile methods for about a decade now at several institutions in Canada, UK, and now New Zealand.

My interest is in the general area of human aspects of software engineering. We look at Agile processes, we look at Agile tools, and we look at actually applying some of those into developing software into novel domains for software developers and in digital health.

Both Martin and I have been involved in several research projects studying Agile processes and we'd love to share some of that information today with you.

Shane Hastie: Thank you very much. So, very wide statement. What is the current state of software engineering around the world at the moment? What are you seeing in the academic space?

Trends seen from research [02:14]

Martin Kropp: One big topic is using AI for software development. That's definitely a huge topic currently. Hard to see where it will lead us really in the future. That's one.

DevOps, of course, maybe less from the academic point of view, much more from the practical point of view. I'm from a University of Applied Sciences, so I'm really closer to engineering. DevOps, it's a huge topic. Including more and more the security issue, DevSecOps is the term for it. Which will probably need much more investigation, how to include these aspects into the software development process from the software engineering point of view.

Don’t automate without first fixing people and process challenges [02:54]

Craig Anslow: I would say automation. I think developers and organizations are looking at how to automate things, make things faster, quicker, and so on. I think AI helps in that context. But also, I think the area that we focus on,  software development processes, is very critical. Without good software development processes, you're constantly in a back fight with your organization of not having an efficient process to actually get stuff done to be able to figure out what to automate. I think that's where a lot of organizations are struggling on the people process side of things.

I think if you solve those, that would lead to better automation. So there's lots of technical areas that are focusing on automation of build scripts, deployment, continuous integration to continuous deployment. Along with the other things, search-based generation of code, search-based interfaces to create code. So automating of code creation, code searching, finding components, making the code work. I think holistically putting that all together fundamentally, if you don't have good processes and teamwork, your project is doomed for failure.

Another important aspect that's developed recently is diversity and inclusion. I'm not focusing on that specific area, but there are various people that are focusing on how to make teams more diverse, more inclusive, and I think that's certainly a hot topic in the space. It's not something I focus in on, but there are other people focusing on that.

Once you start to generate or focus on automation and you bring in AI, there's a lot of people focusing on ethics. What is ethically right to do with the software that we're developing and building? Does it make sense? I think those particular topics, ethics, inclusivity, and diversity aren't my areas, but I'd see that certainly as a hot topic that people are focusing on in the software engineering world.

Challenges of remote work, especially for new graduates [04:37]

And as well as being automating, I think another area that lots of organizations are struggling with, because software is a very transparent abstract thing, is that actually having remote workers. There are some organizations that are not clearly geared up for being distributed or remote, and are struggling to be able to adapt to that. Where opensource companies like the GitHubs, the GitLabs, have been doing that since day one. They're used to doing that.

Other organizations have been forced to do that with the recent COVID pandemic and now are saying, "Hey look, maybe that wasn't actually the best thing to force everybody to do it. We want you back in the office." So trying to focusing on trying to understand better workers' needs and how to best support them. I think the hybrid model, where you are working some days from the office but also working remotely, I think that's certainly a hot topic that software engineering people are studying but also from an organization perspective.

We hear that from our new grads that, "Well, we are a new grad. We want to go out there but we haven't worked in a team physically before. So how do we do this hybrid thing?" So not only struggling from the university studies, so new grads certainly struggle with that new hybrid type of model. So I think there's certainly a lot of need for software engineering organizations to figure out how to best do this and support their teams.

Martin Kropp: You mentioned companies like GitHub or the big digital players like Google. They are developing Agile, or organized Agile from the beginning. I think it's a big issue in traditional companies. I did recently an interview with a guy from a large Swiss bank where they really have the clash between the technical departments, which are organized Agile and also are really product-oriented, and then there are the business guys in the large organization which have a completely different view on how to manage the products and the projects.

There is this clash still. So traditional companies fight really with this current transformation process, and then there's no solution yet really how to do this properly.

Craig Anslow: Yes, so I mean for example, Silicon Valley companies have forced employees to work and live in Silicon Valley. But the recent trend from the pandemic is people want to get out of those places because they can't afford to live there on the salaries that they're making, so they want to go to more cheaper places and work remotely. I think one novel company in this part of the world who does focus on Agile tools and prices is Atlassian, based in Sydney, and they opened up their market for having employees distributed.

As long as they work certain hours within the time zone, they're actually being able to pick up a better talent pool. So I think companies realizing that not everybody wants to live in these specific locations where the headquarters are has actually opened up a better talent pool for some of these companies. I think that's one advantage that the COVID pandemic has actually pushed upon organizations. Organizations that are embracing change, which is an Agile thing, and that change is that the workers want to be able to work where they want to work.

And if you look back at the history of New Zealand, a famous professor, Sir Paul Callahan said, "Go where the talent is," focus on where people want to work. If you can make organizations in remote places like New Zealand, for example, that's where you can build extremely successful companies. Obviously Wētā Digital is an example of that here in New Zealand, in Wellington, where they are producing world-class software for the movie industry in a small, small place. Some of those people are remote as well. But I think that's something that's going to be an ongoing thread going forward. I don't think that's going to go away. You definitely want your organizations to be distributed.

Shane Hastie: So Martin, coming back to the DevOps question, isn't this a solved problem?

DevOps is not a solved problem yet [08:16]

Martin Kropp: From the technical point of view, it might be a solved problem. But here I come back to the business view again, if you can deploy it but you cannot manage it on the business side, the product management, then you have a problem. I think it's more really from the process side and organizational point of view than maybe from the technical point of view.

Shane Hastie: Thinking of our audience, who are technologists, technical leaders, what do they need to do to bring this DevOps mindset into their organization?

Martin Kropp: I think a very strong product orientation, also for the developers. I think there are some top companies who have implemented the DevOps process, and also the technical point of view. But I think a very huge part of the companies recently have a small mandate from a classical manufacturing company, who is still developing very traditional and there is still a huge portion in the market that hasn't yet implemented just the DevOps technologies. So they need to be trained, probably, really very well to adjust to this product view, the DevOps view.

High automation that you have mentioned Craig. Also really implementing including the quality in the development. There's still not very much practiced. We mentioned TDD, I think just a minority of companies are usually applying TDD in a proper way. So now we still have a lot to do, I think, to guarantee the quality that is needed for the product really, for software product.

Shane Hastie: So let's dig a bit further into that product focus versus project focus. What is the big shift there?

Shifting from project to product focus [10:00]

Martin Kropp: I think the big shift is the long-term planning where you, with a project you're focusing on maybe one, two, three years or maybe for larger project five years. But with the product view we have a long-term view. So I think that the whole planning will differ, different kind of budgets from the process and organization point of view.

And from the technical point of view, is that you have really to implement and build in the quality assurance measures from the very first point. So you cannot wait until the end of the project writing tests because there is no end of a project in the product view. You have to build in the quality assurance from the very beginning. There we still have a lot to do in, also from the education point of view to really bring this mindset to the coming engineers that we are educating.

Shane Hastie: Let's talk about that education, what needs to change in the training of software engineers?

What needs to change in the education of software engineers? [10:58]

Martin Kropp: We started recently discussions at our university about this, and we didn't yet find a solution. I mean, offering more software product development-oriented courses might help. I, myself, am teaching a course, it's called Software Construction and another course, Software Testing Quality Management, where we are covering testing methodologies, testing practices in detail. But still, it's an isolated course, so it's not included in the normal programming courses. So students, of course, still then learn programming and learn testing in a different course. So it's still separated, and I think the challenge is to bring this really together, and maybe doing more projects.

We are currently discussing solutions that we really want to develop software products, and students have to continuously develop and evolve these products over many years. So students join the product, and then when they finish the study, they're leaving the product and new students will join the product. That's something we discuss currently. So they have to learn reading code from the very beginning. I think that's something we hardly teach actually, at least at our university, getting to read and understand code, which is probably 70, 80% of what we're actually doing as a software developer.

Yes, we are developing ideas but we haven't yet come to a conclusion. But I think getting to maintain, evolve existing software systems might help to also propagate this mindset of a software product.

Craig Anslow: Yes, I think the advent of the success that we've had in the software industry is that we've built a lot of tools, which means a lot of people can program, which means a lot of people can produce code quickly, which is good. But it's also really, really bad because it means that you're going to come across the issues which are going to be security vulnerabilities, quality of code.

So if we're using this automated generation code generation tools, how do we know that that actually is correct and does what it's supposed to do? I think coming back to your question around software education or software engineering education, there isn't enough people who get properly trained in the software engineering programs. There isn't enough, and AI is getting some programs up and running.

There's cybersecurity programs up and running now. But there ain't enough engineering types of people out there to be able to produce the quality assurances that we need, the security aspects that we need, and just the quality of design.

And so this is where we're getting into issues like technical debt, like security vulnerabilities that need to be resolved, lots of bugs crashing, crash reporting, and so on. So the quality of code is getting worse, I believe, but we're producing a lot more code. So there isn't enough bodies to be able to significantly get properly trained through university education system.

You can learn lots of stuff online, but there's a lot of stuff that you just can't absorb in a few months to get a qualification without actually sitting and doing a proper formal education in this space. I mean, obviously I'm a traditionalist and I'm advocating for a university-style of education, but if you go and do a bootcamp for six weeks to two months, less than six months of a training program and come and expect to be writing mission-critical software, it's just not possible. So it's a balance of having the right level of education for the right type of role.

I think there's always going to be a need for people to be able to produce code quickly and through some of those bootcamps, self-train yourself. But if you look at the fundamental big tech companies, they want people that have studied deep tech to be able to come work on those fundamental systems, the banking systems. You wouldn't just trust a new person that's had not a lot of education and a lot of experience to get there.

The education system is one way for people to get their foot in the door. If you look at places like internship programs, the one here in New Zealand which I'll plug is Summer of Tech. They have about 1000 students on board, 300 jobs. So 30% of people that are going to get internships, that's not a lot of internships that are going, that are available, and there's not enough positions for that. There's a glut of people, but not all of them are formally trained, they're half trained.

Making software engineering an accredited profession? [15:24]

I think the other aspect and the flip side of that, to address that software engineering education question is that once people are unleashed unto the world, they've done their formal training, there's no checkups on what their portfolio of work is doing. So if you're a certified engineer in countries like Canada and so on, you get a professional engineering, you belong to the professional engineering organization, sometimes you have to submit portfolios of work in some of these spaces. But in software engineering, no, there isn't any of that.

A lot of the programs are accredited to the Washington Accord, the standards of programs that are measured for the quality of education, and all New Zealand universities and many overseas are also getting accredited, these bodies. But once you leave the university institution, there isn't actually any formal education. There are training certifications such as Scrum Master, The SAFe, IC Agile, those kinds of programs. But people aren't actually checking the portfolio of work that people are continually doing compared to say design portfolios or art portfolios.

So I think there isn't ongoing training, there isn't ongoing education necessarily that people need to be able to do to perform and say, "Yes, I'm certified." So while they might be certified with these certificates and training things, there isn't actually an overseeing body which is overseeing the certification of this engineering. The catch is, if you do that, then you put a certifying body over the top, then it becomes extremely regulated. I'm not sure that all organizations want to be regulated in that context. Companies that are pitching for bids and so on, they do want to have people that are certified in certain professional programs, but often most of them aren't checking what the undergraduate, or their graduate, or formal education is.

So I do see that there's a greater need for professional education, and both Martin and I teach on professional education master's programs, which are teaching people that have industry experience to come back and do some of maybe that formal education that they missed if they didn't do it as an undergraduate, or clarification or quantification of some concepts and ideas. But I believe there's a good market there for doing more university, formal education or at least not necessarily certified by specific body such as Scrum, or Agile Alliance, or IC Agile, or Scaled Agile framework. If there's some other independent body, I think that would be a good thing that allows people to be able to do that. Then you can say, "I'm a professional at doing this,". You have to submit a portfolio of work, not just to sit on a two-day training course and say, "Yeah, I've done those exercises. I know what those mean, and I can answer those questions," but actually submitting code.

And one answer to that is GitHub, right? You can have a portfolio of work on GitHub and show that stuff that you're open, but then on the catch-flip-side is, if you're working at a private organization, you can't necessarily show the code because it's of NDA and all those kinds of things. So there needs to be somewhere in the middle where people that do want to show that they can know stuff and know things, or keep up that knowledge, that acquisition that you can show that you can do that.

Whereas going into a more sophisticated software, such as safety critical software, very important infrastructure code, those people aren't checked that they still know this stuff. We know as you get older, you start to lose things and you're not as proficient as you are. I mean that's just general life knowledge. So maybe there's a certain point where you're too old to program maybe, I don't know. But then we're seeing rejuvenation of people that are COBOL programmers, because a lot of stuff is legacy code in that space. I think at some stage it would be useful to potentially have some kind of body that allows you to submit portfolios of stuff.

There may be a case of having education programs that support that. So there's a big movement of the craftsmanship, software carpentry led by, I've forgotten the guy's name from Toronto, just momentarily forgotten the guy's name. It never works in theory, but there's people doing that software carpentry programs, which is a form of education and it's basically training people on very specific skill sets. So that's a really good thing. I think having more of those things out there as programs that would help to certify or clarify independent professional practices. I think that's what would be something that I think would be good going forward. That's a really good movement there, software carpentry, and I think we could have more of that.

Sometimes it could be organizations that are leading that as well. So you could be organization proficiently as opposed to we've got X amount of people that are certified in this thing, but that just means that they've done that certification, doesn't actually show the portfolio of work. I think that would be a step. I'm not saying it will work, I'm saying that we should try. You don't know until you try. It could be a bad thing, it could be a good thing, I don't know. But that's just one approach to answer your question.

Martin Kropp: Maybe even for universities, that students not just make a degree in software engineering or whatever, but maybe get a competence portfolio certification where you see, okay, he has competence in UX, in security, maybe in a kind of spider diagram where you see how much has somebody done in this area, in this area, so that we offer different kinds of certificates so that industry sees really, he has competencies into this area.

Craig Anslow: Yes, because I think most of the certifications at the moment that are out there, the Agile processes ones, which I mentioned, but there's also ones that are Microsoft certified, Java certified, programming language is specific certified, and that shows the competency in those things. People are doing those.

But I think if you want something that's more the software engineering, the generalized thing, then there isn't an independent body. Maybe that's something the ACM should be doing or IEEE, something that's quite independent from the rest of a corporation or a university, which as beyond just an undergraduate or beyond the professional certification, that is a possibility. I don't know.

Shane Hastie: Craig, I know an area that you've been actually doing some research in is the junior versus senior engineers, software engineers and the competencies, and how recent grads, junior engineers are fitting in and the difference between the way that a junior engineer works and a senior engineer works. What are some of the things you found in that research?

Research into junior and senior software engineers [21:25]

Craig Anslow: So just a quick summary of that. So it's actually joint work with Martin, and others, and me. We did a survey with industry practitioners, particularly in Switzerland, for several years, which Martin led. Then the more recent surveys that we've been doing across the world in several countries, so Canada, UK, New Zealand, Switzerland as well.

The summary is that we found that the junior developers that have had just a few years of experience, I think less than three or four, were mainly focusing on getting proficient at the technical competencies. The ones that had 10-plus years experience, that are more senior developers, had already mastered those technical proficiencies and were focusing more on the process side of things and the people side of things. That's where we saw the real benefit of adopting some of these practices and becoming more efficient and getting more effective results.

It takes time to master the technical practices, but the more important ones where actually the people practices. Maybe Martin, you want to add a little bit more to that?

Martin Kropp: Yes, exactly what you said. In these studies we put especially focus really on the experience of the developers. Also, very basic technical practices were only used by juniors, like unit testing or continuous integration. More advanced like TDD or ATDD were only really then applied later with more experience by the senior developers. So even on the technical practices side, the more experienced one use approaches, advanced topics like TDD and ATDD. So I think that's something we can work on and try to bring these technical practices also earlier to the junior programs, so that they really start from the very beginning to apply them.

But the major finding was indeed that the process and organizational issues, they really take time, because they are combined with the cultural change in organizations. They are more, then, applied by the senior developers.

Craig Anslow: You can find some of the research on the The Swiss Agile Research Network website.

Software development is a stressful profession [23:27]

Additionally, what we did find is that regardless of junior, intermediate, or senior, which we studied in the breakdown, is that Agile is stressful. It doesn't matter if you're a junior or a senior, it's stressful regardless. So I think one of the things with the Agile movement, which has been around 25-plus years, is that they were trying to make Agile less stressful. But it hasn't actually done that at all. It is still stressful.

So software development is still stressful regardless if you're a junior or a senior person. This result of the studies that we have found, do we have a silver magic bullet to make it less stressful? I think the answer is no. I don't believe it's ever going to be non-stressful. It's a job, it's work, it's productivity. How do you make it less stressful? I'd say retire and go to the beach. But that's not going to happen. People have got to pay their bills. So I think there's some things that we can do to make the environment better, but in general we found it was stressful, regardless.

This is a very small study, several hundred people, so in the grand context, there's millions of developers around the world. So more research would certainly need to be done to clarify that, in different situations, in different organizations, and so on. But the few studies that we've done, we've found it as stressful.

Shane Hastie: It is a high pressure career.

Craig Anslow: Yes. The rewards are good too, right.

Shane Hastie: We touched a little bit on automation. Let's go deeper. The AI tools, how are they helping us, and how are they potentially hindering?

Model-driven engineering is not being used extensively [24:52]

Martin Kropp: I think it's, at least for me, it's not that clear where the way will go with AI tools. They can help us really generate code. They might even help us to generate tests that test the generated codes. So in this way they might help to automate the code generation really. Myself too, less experienced with using AI tools for software development. But that might be a way how it can help us to automate, really, code generations.

Craig Anslow: I think there's another movement there that's been overlooked recently, in the last few years with the impetus of AI, and that's modeling, UML, diagrams. So there was a big movement in the model-driven engineering community, and it still exists and it's still doing pretty well, from what I can see. I have colleagues working in this area. That's to push model generation to write, and automate, and generate code.

So that was all about code generation from diagrams and pushing the designs from a business analyst gathering requirements, writing diagrams, working with the developers, talking to customers, producing designs of the diagrams of what the code would look like, and pushing out templates of code, which you would then fill in the algorithms. I mean, we're doing the same with AI here in that context. To me, the studies that we've found, there isn't a lot of people doing model generation in practice. There are some toolings out there, and you can speak to some of the gurus in the UML world.

AI tools can help with some aspects of code generation [26:17]

But in general, we've done studies as well, that also ask people do they use diagrams? Do they do modeling tools? A well-known paper from Maryann Petri from XP 2013, she said that about 50 people that she interviewed, only about 9 of that 50, I think it was 9, we're actually only really using UML diagrams. So there's a very small percentage, in general. It's a very small study again, but the purpose of model-driven engineering was to generate code through models.

It's the same with AI, that I think the same here will be a series of experiments, lots of people trying to generate code using tools like ChatGPT, which I don't have a lot of experience at, and it's only been out for just over 12 months. It's not been able to talk for very long. Lots of people are using it to generate various things, and some of that is code.

The question is can it produce complex code? I somehow doubt it. It can probably generate good outlines and frameworks and so on. But there's still the level of detail, still the hardcore software engineering aspects, the very niche IP of the algorithms and so on, which is very unlikely to be able to be generated by AI, or these tool generation things. So I think you'll still need that human element, but is there are a tooling out there that can actually expedite some of the things that we can do that make some of the grand nuts and bolts really slow, faster? That would be great.

So for example, the movement of refactoring, Bill Opdyke wrote a PhD on this, a nice book by Martin Fowler called Refactoring, and there's a whole bunch of discussions around how do we refactor code? Then some of that stuff's now been integrated into IDEs where you can do Extract Class to create, getter and setter methods, your mutator accessor methods and so on. There's things like that. So the tooling has helped automate some of the refactoring. So I see something like that, where you can use AI tools inside your IDEs to generate some of the code that you actually want to be able to do.

People have been doing diagrams and doing hand recognition to create models that then generate a code. So I see that some of the stuff will be integrated into the software development pipeline. It's got to be, it's speeding things up. So I think it will certainly get there. I think the answer is, we don't know specifically what will be successful or not. So I think probably over the next decade time, going back to your other question is, I think lots more experiments will be happening around software engineering and AI. And that's a pretty hot topic at the moment around generation, around code finding, code searching and bugs, right? Debugging.

We are doing a project at the moment around crash reporting using genetic programming. So clearly we are using AI ourselves. We're not experts, far from it. But we are using existing methods to actually look at how to report crashes and software bugs, in particular JavaScript programs.

So I see lots of experiments using AI techniques and tools, and developing and extending those, and actually helping software developers. I do see that that is something that is going to happen. There's going to be more of it. Going back is, we don't talk about we're doing refactoring, but we are doing it. So another paper by Emerson Murphy-Hill and others saying, we know we're refactoring. Well, I can't remember the actual title of the paper, but it's not about we are specifically refactoring, we are actually doing it.

We just don't thinking about it. So I think the issue now is that AI is very prominent, and we're thinking about doing AI at the moment. I think in future years it'll just be common practice. So I think it'll just be something that we do not actually give it a label. That's probably something backed with Agile. We are doing Agile practices, but we don't think of it as Agile. It's just something that we do.

Martin Kropp: I completely agree. I think it'll not be a revolution, the AI tools. It's much more an evolution on different levels, as you said. Today, you can integrate Copilot in your IDE and it really helps a lot in coding. It makes, very often, very good suggestions. So it helps on the low level to generate code and improve the code.

If we will really be able to generate code from a short description or whatever, or complete programs, I think that's something the future will show. I think that will be really adapting the tools, improving the tools. So it will be much more an evolutionary process, in the Agile sense, as you said. So I think the way we'll go in this direction and how it'll end up, we will see then.

Shane Hastie: Interesting stuff. I'd like to end with advice for young players, advice for junior software engineers. They've done the training, they've got the basic skills. What should they be looking at and thinking about?

Advice for young players [30:42]

Martin Kropp: Maybe coming back to the article from ... What was it, "Back in Gamma, Love to Test Software?" Yes, in the sense really, start loving building quantity in the code. I think that's very important for the future, because it will need to be able to- with the whole digitalization of the economy, we need to be able to really deliver products very fast. For this, you have to build in the quality from the very beginning.

Craig Anslow: Yes, I would say learn as much as you possibly can. Try different languages. Don't be set on just one specific programming language or one specific framework. Try different things. Try different organizations. Do not burn your bridges. Always move with integrity. I think it's also worthwhile exploring different domains as a software developer, working in the healthcare sector is one, but working in financial tech, and you learn different things from different domains and applying those I think is really useful. Spending a few years in each of the different domains would be particularly useful.

I think the advantage now is, we didn't quite discuss it in detail here, is that the pandemic, COVID, has actually opened up a lot of opportunities for companies to employ people from all around the world. So I think depending on where you live, definitely look at some of these remote-type positions. So you don't necessarily have to travel to those other distances to work in those countries, because visas, and issues, and stuff like that can be the problem to get into some of these countries.

But working for different companies remotely, or even overseas, I think would be a good thing before you settle down with your life, whatever that happens to be. But getting experience for other cultures and other organizations, the way that people do things, and learning different techniques and languages.

And continuing to learn the whole time. I think that's one of the things if you look back at Agile, and one of the things that my colleague, Alan Kelly always says, and which is also true in the Agile movement, is, "If you're doing the same thing after three months, you're not doing Agile." So if you keep doing the same thing, and that's the same with, I think, junior people, I think they need to keep learning and keep doing new things and trying things.

Part of being a software engineer and having that craftsmanship is being able to learn, and adapt, and try different things. If you're not continuing to do that, you're not doing your self-learning. Then that's one of the things that, if you look at the Agile Manifesto, talks about is learning, self-reflection, reflection in general on your team processes, but also individual. I think that's something that I would always encourage young people to do is just keep learning.

It doesn't necessarily need to be a formal education, it doesn't have to be a certification, but online learning, there's so many resources out there from compared to 20-plus years ago. There's just an abundance of information and you're not going to learn it all in one day or a few days. It's going to take a lifetime generation. But I think having that hunger and that need to learn would be my best piece of advice.

Shane Hastie: Gentlemen, thank you so much for taking the time to talk to us today. Really interesting conversation. If people want to continue the conversation, where do they find you?

Martin Kropp: You find me on our website, of course, Martin Kropp at the FHNW website. Happy to answer any questions or remarks also you have.

Craig Anslow: You can find me in Middle Earth, middle of Middle Earth, which is in Wellington, Aotearoa, New Zealand. I work at Victoria University of Wellington. You can find me there, or Google me, Craig Anslow, Twitter, LinkedIn and so on.

Shane Hastie: Thank you so very much. I'll make sure all of those links are included in the show notes.

Mentioned:

About the Authors

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT