I started learning to code in the late 1990’s using gcc, make, and emacs. <\/p>\n\n\n\n
The 2000’s were a huge pivot point in Software Engineering. Three major changes which were very related came together to fundamentally change how software saw built. First, modern IDE’s changed how coding was done. Second, high level languages like Java, C#, and Python became more usable. Third, agile fundamentally changed the way that engineers worked with businesses.<\/p>\n\n\n\n
These changes are definitely linked in my mind. In the 1980’s and 1990’s coding was a job. Being a good coder was enough. By the 2010’s that had all changed. Coding was a part of the job, but being a great coder alone really didn’t get you anywhere. <\/p>\n\n\n\n
As a Software Engineering Manager I evaluate my team on three primary skills.<\/p>\n\n\n\n
Do you write clean code?<\/p>\n\n\n\n
Do you make good architectural decisions?<\/p>\n\n\n\n
Do you understand the languages and frameworks?<\/p>\n<\/div>\n\n\n\n
Do you understand the requirements?<\/p>\n\n\n\n
How well can you communicate with stakeholders?<\/p>\n\n\n\n
Do you understand secondary and tertiary effects of changes?<\/p>\n<\/div>\n\n\n\n
Can you run agile ceremonies?<\/p>\n\n\n\n
Can you work with product team on change management?<\/p>\n\n\n\n
Do you understand non functional requirements like performance and audit?<\/p>\n<\/div>\n<\/div>\n\n\n\n
I have found that a strong team will have a balance of these three criteria. Each engineer should have some proficiency in all three, and the team as a whole should be strong in all three. <\/p>\n\n\n\n
The interesting thing about these criteria is that they aren’t easily replaced with AI. <\/p>\n\n\n\n
Even in technical expertise where it performs the best, AI will definitely hit it’s limits in architecturally difficult problems. It tends to produce bloated code that is not as easy to maintain as clean human code. <\/p>\n\n\n\n
The domain knowledge criteria could be interesting. I would love to see deeper integration of AI with Jira. Using a company’s internal documentation to help evaluate new user stories and ask follow up questions could really augment team’s ability to plan effectively. <\/p>\n\n\n\n
I’ve been using Copilot for a few months now and I actually really enjoy it. I think that it’s a great tool that will advance the productivity of software engineers, but I am not worried that it will start to replace human software engineers in enterprise environments. Like the IDE, it is a potential huge step forward in engineering effectiveness. <\/p>\n\n\n\n
I also see a place for vibe coding in the code spike\/proof of concept phases of a project. An engineer and a domain expert spending a few days in a conference room could quickly knock out a prototype with these tools. As long as you aren’t expecting a production ready\/scalable system then vibe coding can help businesses hash out new ideas. <\/p>\n\n\n\n
Software Engineering is far more than coding. I love tools that can make the lives of software engineers better, and AI is a new tool in this category. Talented software engineers will have a place in businesses for years to come. <\/p>\n","protected":false},"excerpt":{"rendered":"
I started learning to code in the late 1990’s using gcc, make, and emacs. The 2000’s were a huge pivot point in Software Engineering. Three major changes which were very related came together to fundamentally change how software saw built. First, modern IDE’s changed how coding was done. Second, high level languages like Java, C#, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-93","post","type-post","status-publish","format-standard","hentry","category-software-engineering"],"_links":{"self":[{"href":"https:\/\/agilecongruence.com\/index.php?rest_route=\/wp\/v2\/posts\/93","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilecongruence.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/agilecongruence.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/agilecongruence.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/agilecongruence.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=93"}],"version-history":[{"count":16,"href":"https:\/\/agilecongruence.com\/index.php?rest_route=\/wp\/v2\/posts\/93\/revisions"}],"predecessor-version":[{"id":110,"href":"https:\/\/agilecongruence.com\/index.php?rest_route=\/wp\/v2\/posts\/93\/revisions\/110"}],"wp:attachment":[{"href":"https:\/\/agilecongruence.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=93"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilecongruence.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=93"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilecongruence.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=93"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}