Tag Archives: Engineers

The Value of Contributing: Mentorship

I found this interview on the JetBrains YouTube Channel really interesting:

Zig 2026: No-AI Policy, $670K Foundation, Left GitHub & Why Zig Isn’t 1.0 – Andrew Kelley Explains

Some developers really love to code. They share their code and they mentor others to share their code as well. The entire process is a challenge for them. It’s their passion. It’s their craft. And for these guys they aren’t casually dumping their entire development experience for the latest automated AI system to come along.

Here’s Zig Software Foundation lead Andrew Kelley during the interview:

“I love computers. And I love learning about what people are doing with them. And there’s a sense of mystery and magic that you can get from reading someone’s explanation of a project that they did that took them a very long time. They had to learn lessons, and they had to increase their skill as a programmer and as a user of computers in order to accomplish this goal. And when you read a blog post like this, it’s brilliant. It captures the imagination. It makes you think about what you could do yourself. It teaches you something. It connects you to them emotionally.”

And that’s why Andrew bans the use of AI on his Zig projects.

Instead, he’s seeking that close connection with his contributors. He’s seeking excellence and discovery from the many procedures involved in software development. I picked up on this attitude right away because I’ve interviewed many engineers about the value of contributing. Many of them hold remarkably similar views to Andrew, and they talk at length about the importance of contributing to the community.

Here Andrew explains it beautifully:

“The main point of doing code reviews and having contributions, instead of us just doing all work ourselves, is mentorship. The whole point is that a contributor can become a core team member eventually or a more valuable contributor. This will help the project because we’ll have more people who can contribute to Zig skillfully. And it will help their resume because they’ll be a better systems programmer, and they can then take those skills elsewhere.”

But the contributions Andrew used to get from developers using AI were “garbage and had no value whatsoever,” he says. That’s pretty strong language. But Andrew has very high standards and would prefer to engage developers directly on their contributions during the code writing, review, and integration process. That’s where he builds valuable, long term relationships where contributors become more skilled, the core team benefits, and the product maintains the highest quality possible. AI, he says, only gets in the way of that process.

Education is also a big reason for why Andrew holds this view.

“This policy just makes sense because the Zig project is also an education project. That’s part of our mission statement. We’re providing guidance and education to students. So we’re all trying to learn. We’re all trying to get better at programming. And so people who are sending AI pull requests, those people are not helping this goal. In fact, I think that they’re detracting from this goal. So, for our project, I think that the strict no AI policy is an appropriate policy.”

Many times websites bury their organizational mission statements down at the bottom of the page or tucked inside a nav element. But on the Zig Software Foundation site, it’s printed right at the top as the first item.

For developers using AI, Andrew says, it’s simply not worth investing in them. “They aren’t going to join the core team later, not a chance,” Andrew says. It takes too much time away from the reviewers, and the contributors don’t learn anything in the process and are less likely to stick around. Andrew isn’t just saying this, though. His team has tried taking AI contributions but it hasn’t worked out, and they still have hundreds of contributions that still need reviewing. So he’s speaking from his own experience. He’s actually quite thoughtful about the whole thing, so it’s hard to argue that he’s just making a mistake or that he’s blind to the emergence of AI.

So, what’s the lesson? Learn your craft. Learn it well. Go deep into the details so you can demonstrate your expertise so that it’s unmistakable to more advanced developers. And look at the entire process as a community building exercise. In other words, it’s personal. It’s more than just code. Don’t outsource that opportunity to a machine. And then you can build lasting human relationships with the core team via iterations about your code that you submitted yourself. That’s a powerful signal to send into the noisy world of software development. It’s also a simple technique that can be applied to any field you choose. All craftsmen in all trades know this.

Andrew’s position on AI may fly in the face of the current trend of developers embracing AI tools, so we’ll have to see how he and his project evolve as AI grows to pervade more levels of software development. So far, though, Andrew remains emphatic. And judging from many of his comments throughout the interview and how deeply he gets into system development, I bet he sticks to that view. At the end of the conversation, Andrew says he’s probably unemployable at this point and is best suited to be on his own. He’s clearly an entrepreneur at heart, and his standard is “uncompromising perfection.” Can’t argue with that.

And finally, here’s a shout-out to the JetBrains team for talking to Andrew, who said flatly in the interview that he doesn’t use JetBrains products because he only uses FOSS software. Even with advanced IDEs on the market, Andrew’s development set up remains simple and open: “It’s just a terminal and Vim.” Like I said earlier, he loves to code, And he seems as hard core about that as you can get. But the important bit for JetBrains is that they had him on at all. The interview has nearly 900K views in just three weeks, which is vastly more traffic than other recent videos on the channel. Most software vendors would never do this, no matter what traffic a guest could generate. Most vendor channels exist to simply sell products. But JetBrains with this decision demonstrates that they are also concerned with promoting excellence in software development and in building the overall software community. Good for them.

A Double Standard Around AI?

If you follow technology, it’s obvious now that many software engineers speak openly about letting AI agents write their code. And most developers are praised for that move. On the other hand, writers who use similar AI tools to draft their prose usually get a vastly different response. They actually face harsh and sometimes nasty criticism. Why the difference? Both groups use AI, yet the social judgment for each draws radically different reactions. Does that represent a double standard? The two crafts share some things in common, but they certainly aren’t exactly the same so comparing them may be difficult. But they are close enough so we’ll give it a shot.

How Developers Worked Before AI

Picture how developers built software before AI. Roughly speaking, they started with a problem, broke it into pieces, and thought through a basic architecture before typing any code. They chose data structures, wrote functions, planned testing, and reviewed edge cases with team members. When things broke they found the bugs and fixed them. They reviewed their own work and asked colleagues for reviews as well. Every choice in the finished code passed through people. The process was slower by today’s standards, but that slower pace often encouraged developers to think carefully about what they were building before anything integrated into the final product and shipped to customers.

How AI Changed the Developer’s Process

Compare that older process above with how many developers work with AI today. They still start with a problem and break the work into pieces. But the main change now is that they write detailed prompts into an AI system instead of typing their own code. A good prompt can name the files or modules, state the tech stack, describe the desired behavior, and list any constraints. The more context that can be specified up front in the prompt the better. An AI tool then produces some draft code, sometimes across many files, that touch many parts of the system. Developers review the output, run the tests, fix bugs, update the code, and tighten the result. They iterate with the AI as needed by refining prompts or making direct edits to the code themselves. For routine tasks such as boilerplate, tests, or simple refactors, the AI seems to save time for most developers.

For more complex logic or significant architectural decisions, developers still do the initial planning for the project, and they remain responsible for the final code. However, most recently the job has shifted significantly with developers directing multiple AI systems to do the work. This is generally described as managing agents, and it’s characterized as a sign of technical sophistication. Of course, careful human review of the code remains essential for serious work. But a smaller group of developers say they now rarely open the generated files at all because they believe the AI systems are reliable enough. That more extreme group sometimes draws criticism within engineering teams if developers can’t explain or fully own the resulting code. Nevertheless, this trend toward the edge continues and seems to be increasing. Will it mark the new standard in the years to come? There are good arguments on both sides.

How Writers Used to Work Before AI

Now let’s shift to writers. They went through a similar process change as engineers did but on their own, much longer timeline. For them the old way meant research, outlining, interviewing, drafting, and editing using their own editorial or manual tools. Writers wrestled with ideas for days or even longer before they carefully crafted characters and scenes onto the page. They revised their text, cut what didn’t work, and sharpened what did. This iterative process could go on for quite some time during the drafting process. Aside from formal copy editing that came later, the voice on the page belonged exclusively to the writer because every word was written by hand.

How AI Changed the Writer’s Process

Modern AI systems potentially change all of that. Writers can now hand an AI their rough notes, ask for some background research, and get a full draft back in minutes. That may be an oversimplification, but it’s not that far off. From there writers can edit to whatever degree they want to make sure that more of their own voice survives from the original AI-generated text. Writers can even train the AI beforehand to write as closely to their own rhetorical style as possible to reduce the final editing process. So, the starting point for writers has moved from a blank page to a rough draft or even sometimes a seriously advanced machine-generated draft extremely quickly. That shift is similar to a developer’s starting point moving from a blank file to a block of generated code that works as specified.

Reactions to the Two Fields Split Radically

The two examples above aren’t exhaustive or even totally parallel, of course. Developers are much more used to automated systems that aid in building software, whereas writers have not traditionally had tools capable of generating substantial amounts of finished prose immediately. Nevertheless, here’s where the paths split significantly. Although the work itself is similar to some degree, how the world responds to the work is radically different.

When developers say their AI agents wrote most or all of their code, people in the field and observers online often call it efficient and innovative. Companies hold it up as the future because faster delivery requiring lower headcount translates into competitive advantages in the marketplace. That argument is pervasive right now. And engineers who still code everything by hand often hear that they’re falling behind the times. So the bias toward using AI is the clear standard for software development.

However, if writers say the same thing the reaction totally flips. If writers brag that AI drafted a chapter, even one rewritten by hand many times, readers and critics immediately express outrage. Editors ask writers questions they’d never ask developers. Some publications ban the practice outright. Many schools and teachers do as well. The finished piece gets picked apart for tells, real or imagined, in a way finished code rarely does.

To give just a small example of how fast this issue changed on the tech side and how it still lags on the editorial side, check this out. We were told at my last job just last year that we were absolutely forbidden to use AI for anything at work, and then just a year later, virtually overnight, we were absolutely required to use AI for pretty much everything we did. Rapid changes in strategy like that are normal for tech. The editorial community, however, still grapples with even touching AI for any of their tasks. Attitudes in the two fields couldn’t be more different at this point.

Why the Judgment Differs

Part of this disparity comes from how each field values quality work. Computer code has a cleaner set of qualifications. It runs or it doesn’t. It passes the tests or it doesn’t. Users either get what they need from the software or they don’t. But prose has no such test. Readers respond to the human voice and the sense that a particular writer shaped those particular words. And that feeling seems especially sensitive to most people — even for software developers! It’s odd, actually, because I’ve seen many developers who brag they no longer write their own code simultaneously say they’d never read or trust a technical article — or any article — written by AI! I’ve also seen some developers who strongly promote Open Source software violently balk at the notion of releasing their own articles, artwork, or photography under an Open Source license such as Creative Commons.

So, it’s clear that code and prose (and other types of content) are treated vastly differently. If readers and editors, and even developers, learn that a machine had a hand in the editorial process to produce prose then I guess the literary spell and the trust relationship breaks, even when the finished text shows no obvious signs of having been produced by a computer. I don’t get that, to be honest. But I guess some of this just comes down to personal preference.

There’s another piece to this puzzle, though. Code has always been written primarily for a machine to execute. A developer might read it later, but the first audience was the compiler, which flags bugs and turns source code written by an engineer into machine code or bytecode to be executed by the computer or a virtual machine. Success meant that the computer did what it was told to do. Prose never worked that way. It was generally written by one person for another person. It only started roughly drifting toward a machine audience recently, first for search engine optimization years ago and now for AI systems that write, summarize, and reuse text.

That difference in history helps explain part of the discomfort readers feel when they consume AI content. Writers may not realize this but engineers using AI agents are actually extending a close relationship with machines that already existed. Developers have always used the latest software tools to help in the code writing process. But writers using AI are now altering a world that used to belong almost entirely to readers. And readers can feel that shift even when they can’t always name it clearly. We’ve all had the experience of reading purely AI-generated prose. It just feels different, right? And most people wouldn’t want to sit on a beach someplace on vacation reading the latest novel written by a computer.

The tools themselves are also at different stages. AI coding systems have become reliable enough for real production work on many routine tasks and even some advanced ones. And the ways developers can generate, test, and evaluate generated code are often more sophisticated than the ways writers can generate and evaluate the quality of generated prose.

Internal Cultural Standards in Software

But even inside the software industry there are different cultural standards. Programmers who let agents generate code without closely reading or understanding the code are often described as vibe coders, and plenty of other engineers still push back hard against the practice. For them, their standard sounds a lot like the one writers get held to. For example, if they review what the AI produced, test it, and can explain how it works, that counts as real development no matter how much the AI contributed. If they can’t do any of that, though, it doesn’t count. Writers face nearly the identical test. The difference is where that judgement line is and how easily it’s moved. Inside engineering, plenty of AI use still clears the bar and earns credit for the developer. But in writing, even heavily revising an AI draft, it seems that writers can’t clear the line at all, at least not in the eyes of the people judging the finished product.

That explanation only goes so far, though. It doesn’t fully account for why engineers who fail their own field’s test, the ones who openly say they barely glance at the code, sometimes still receive praise for their candor or for embracing the future. Writers would absolutely face a much different reaction for the same admission. So although the work has moved in the same direction in both fields, the judgment certainly hasn’t.

Where Pride in Craft Can Move

None of this is new to developers. Long before AI, many engineers took real pride in writing their own code, not just in what it did as a final product. They argued over whose solution was best. They refused to publish something messy. An ugly or inefficient implementation was an embarrassment even when it worked. They took great pride in authorship with the same instinct that drives writers to protect their phrases, sentences, characters, and scenes. The difference between the fields was never that developers lacked that instinct for craft. Instead, it’s that the instinct for craft in software development had somewhere else to go once AI arrived. And this is a subtle point that the editorial community doesn’t seem to get yet.

For most developers, though, the code was always ultimately a means to an end. The real deliverable was a working system, and the code was the best available way to produce that system. Pride in the craft and the final outcome pointed at the same target for a long time, so nobody had to choose between them. AI broke that link. Once a working system could exist without hand-written code underneath it, the pride had somewhere else to move. It shifted up a level to the architecture, the judgment behind what got built, and the skill in directing agents to write the code. So, the developer’s identity didn’t simply disappear with AI. It just relocated to a layer AI hasn’t fully reached yet. It remains to be seen how developers will react when AI can cover the entire process, perhaps writing machine code directly without source code or maybe enabling non-coders to produce the exact same output as the engineers with virtually no technical input at all. Some say we’re getting close to that reality right now. Personally, I doubt it. There’s much more to software engineering than just writing well-specified source code or producing a final software product.

Why Writers Have Less Room to Move

For now, though, writers don’t seem to have an equivalent layer to retreat to so that their identity remains intact. And the reason may be structural. Developers hide code behind a working system that the user never sees. That’s by design. Two completely different codebases can produce an identical user experience. The code, no matter how it was written, remains quietly behind a layer of insulation doing the work so the product functions.

But prose has no such layer. A reader doesn’t experience some abstracted effect that the sentences produced somewhere upstream. A reader experiences the sentences themselves directly as a new world gets created in their minds as their eyes scan the text. Change the words and you’ve changed the actual thing being read and the world that’s being created. The sentence is often the final product in a way that code usually isn’t. So there’s no equivalent shift available for most writers. Will that change as readers grow more familiar with AI-generated text? And what happens when AI agents can craft long works directly in a specific writer’s voice without any human or machine detection? At that point, perhaps reading the latest novel on the beach written by a computer won’t be so bad after all. We’ll see.

Markets, social pressure, and personal preference all reinforce these views for now. Software users and companies primarily care whether the system works, how much it costs, and what value it produces. But most readers of prose still treat the human relationship with an author and the sense of a particular mind behind the words as part of what they are buying. Countless readers return to text over and over again simply to experience the pleasure of how specific passages are crafted. And people re-read books many times to learn deeper meanings over time. Authenticity is a timeless cultural preference here. It’s part of the very product itself for a large share of the writing market.

Copyright and the Writer’s Dilemma

There’s another structural difference that writers face and developers largely don’t. That’s copyright. For a writer, publishing text that contains significant AI-generated material creates a genuine legal and commercial question. Under current United States copyright law, purely AI-generated expressions aren’t protected simply because a human prompted the system. Although a larger work can still receive protection when a human author contributes sufficient expressive elements, but the boundary depends on the specific work. For now, humans at publishing institutions are making those judgments through various editorial policies and cultural practices.

Regardless, this distinction is still uncomfortable for many people. A writer who generates a chapter and publishes it essentially unchanged may have little or no copyright claim to the AI-generated expression itself. But a writer who uses AI as a starting point and then substantially rewrites the material may have a stronger claim to the human-authored portions. The machine can make the work easier to produce while also making the boundary around authorship harder to define. This is one reason the reaction to AI-assisted writing may not rest entirely on questions of linguistic purity. There’s a real intellectual property question here.

But developers face copyright and licensing questions as well. Code has to fit inside an intellectual property framework involving employment contracts, proprietary software licenses, or Open Source software licenses. A developer may need to worry about whether AI-generated code resembles existing copyrighted code or incorporates material subject to a particular license. But the question of whether the developer personally authored the expressive work is usually less immediate. For writers, though, the words themselves are the final product, so the copyright question is personal and potentially significant.

Patents and the Developer’s Emerging Concern

Writers aren’t the only ones with legal exposure, though. AI may complicate the situation for developers as well because of patents, which affect developers working on genuinely novel inventions. Although AI-generated code doesn’t automatically create a patent problem, the issue does need consideration. Patent law is concerned with the invention and with who actually conceived it, not necessarily who typed the code. The United States Patent and Trademark Office’s current guidance says the same inventorship standard applies whether or not AI was used. AI can assist a human inventor, but only natural persons can be named as inventors.

That creates an interesting problem. Suppose developers know what they want to build and use AI to implement a technical solution they had already conceived. That’s one thing. But then suppose developers give the AI a problem and the AI comes back with the novel mechanism that actually makes the invention work. Developers may have directed the system, but direction alone doesn’t necessarily establish inventorship. The important question is whether the developers made the required contribution to the claimed invention.

An AI-heavy development process could eventually create a strange reversal. Developers may end up with more efficient code and a better product but also with less certainty about whether their contribution was sufficient to establish inventorship of the underlying technology. Here’s where AI could actually earn its characterization as true artificial intelligence because in that case it would be part of the creation process itself.

There’s another issue too. Developers working on potentially patentable inventions need to be careful about what they put into external AI systems so they don’t inadvertently expose trade secrets. But the problem is broader than trade secret law. Developers have contractual or employment confidentiality obligations even when the information does not qualify as a trade secret, and these things can’t be violated as well. Patent law also depends heavily on novelty and timing, and public disclosure can lead to consequences that vary by jurisdiction.

The safest approach is to keep track of what the human actually conceived, what the AI contributed, and where any confidential invention details were sent during the development process. This can obviously get complicated as the use of AI becomes pervasive and as swarms of agents handle more and more complex computer science tasks autonomously.

So, although not exactly the same, patents can be a useful counterweight to the copyright comparison. Developers may not have the same immediate authorship problem as writers have, but they aren’t completely outside the intellectual property problem either. These legal questions have simply moved to different layers for each field and will need to be ironed out in the courts as issues come up.

Institutional Rules Differ Too

Institutional rules and agreements reinforce the disparity between writers and developers as well. For writers, publishing contracts, academic policies, and editorial standards still treat AI contributions as something that must be disclosed or even banned outright. But software employment contracts and Open Source development practices treat AI assistance as ordinary tooling with far fewer formal restrictions.

There’s yet another wrinkle in the rules game: international regulations. The European Union is beginning to treat transparency around AI-generated content as a regulatory issue. The EU AI Act’s transparency obligations under Article 50 came into effect on August 2, 2026. Among other things, the rules require certain AI-generated or manipulated text published for the purpose of informing the public about matters of public interest to be identified as artificially generated or altered. There are exceptions, though, including situations involving human review or editorial control. So this is not a blanket requirement that every article or book touched by AI carry a label.

That’s interesting when you consider the difference between writers and developers. A person reading an article may have an interest in knowing whether the words were generated by a machine, particularly when the article is intended to inform the public. A person using a piece of software, however, generally has no comparable expectation that they should be told whether an AI agent wrote some or all of the underlying code. The EU rules could, therefore, suggest a broader distinction between AI used to produce code in a software product and AI used to produce prose in a book that another person consumes directly.

The EU is also putting copyright obligations directly on providers of general-purpose AI models. Those frontier providers must have policies for complying with EU copyright law and must publish a sufficiently detailed summary of the content used to train their models. The relevant obligations for general-purpose AI providers began applying in 2025 with the European Commission asserting enforcement powers over those obligations in August 2026. At present, most major model providers are complying or plan to comply.

Even this issue is still developing. Different countries will continue to approach AI, copyright, patents, and disclosure differently. It’s probably too early to tell whether these regulations will create a permanent distinction between writing prose and writing code, or whether that line will blur as AI becomes a normal part of both professions.

What the Split Inside Software May Suggest

Although the software industry has generally and enthusiastically embraced AI, not every developer is making the shift easily. The ones who built their identity on demonstrating individual skill, the tightest solution, or the best line of code still feel a loss that looks remarkably like what writers describe. For them the code was never just a means to an end. It was closer to the point itself, and you can see that feeling come through passionately in many reactions on social media as developers are forced to use these new tools.

People in both fields also worry about the next generation. In software the fear is that junior developers will never build the necessary technical skills to understand, debug, or design complex systems. In writing the fear is the loss of voice, critical judgment, research skills, and the long apprenticeship of writing as a craft. Watching some developers relocate their pride with ease while others struggle to let go of authorship suggests that the split may run through personal temperament more than through evolving professional standards. Writers may be looking at a preview of their own future in that split with some finding a new place to put their pride and others not finding one at all.

Maybe there’s another difference that will become more important over time. Software has always been layered. A developer can move from writing code to designing systems, then to architecture and product decisions, and eventually to deciding what problems are worth solving in the first place. Writing and editorial production has layers too, but the final expression remains the exposed text. An author can move toward research, structure, editing, or directing AI, but eventually the reader still encounters the words themselves. If those words can be produced almost entirely by a machine, the question of what exactly the writer contributes becomes harder or impossible to quantify. Each profession will have to establish a new definition of meaningful human contribution and quality of work.

There’s no obvious answer yet. Things will remain messy for a while. The technology is moving too quickly, the law is now moving along with it, and opinions are not consolidating. The European rules are only beginning to take effect, the copyright questions are still being worked out, and patent authorities will have to apply old concepts such as inventorship to a technology that didn’t exist when those concepts were created. So, it may be that the differences between writers and developers become smaller over time. Or the legal and cultural systems may end up actually reinforcing the differences.

Never Ending Change

For now these are just some questions worth watching. Maybe the honest answer to the original question about the double standard is that there really isn’t one. Despite sharing some common characteristics, the two fields are structurally different enough so AI will simply be implemented differently for both. Who knows how this will turn out. I guess we’ll all just grind our way through it to some conclusion or another.

Investigating New Projects

A managers view of how to do initial investigations into new projects.

Hey, engineers, how many times have you been casually asked by a manager to go look at [insert whatever] project because we need it now? And how many times have those initial conversations been productive? It’s probably more likely that non-specific instructions delivered on the fly like this only lead to confusion as managers and the engineers struggle to get in sync about who wants what, when, and why.

So, after observing this game for many years, and after watching some highly skilled engineers navigate these nebulous exchanges with managers, I wrote up some tips for people to follow when they are asked to investigate some shiny new project.

During that First Meeting

Write down the project goal! Be sure you understand the problem you are being asked to solve and all constraints known at that time. Remember, though, that all the constraints won’t be known initially so expect some ambiguity. That’s part of why you are being asked to investigate the issue.

Most important: Ask right up front about the underlying problem. In other words, a manager just directing you to go build A isn’t sufficient. You should want to know why. What’s the problem? Get that data first because you may be able to solve the issue by building B instead of building A. And the manager may have not even considered that.

Collect as much information as possible from this initial meeting. Ask questions. Take notes. These notes will come in handy when the manager later dives off into the weeds, especially after talking with a few executives or customers, so you’ll need to pull him or her back on track.

Finally, don’t just say ok and walk out. Always respond that you’ll need to do some preliminary research before making any commitments and that you’ll get back to the manager in a week or two or some agreed upon time.

Starting the Investigation

Remember that you need to do work as part of your investigation. Simply reading or searching or consulting with colleagues is not enough to discover enough information to report back to the manager.

Is it possible to get a really rough prototype working? What’s missing? What’s possible? Even just trying to get something going is better than not making the attempt at all. The point is that you should invest some focused time doing work. Don’t just read up on net searches.

Start a rough task list. Think in terms of iteration. Task lists are flushed out over time as new information is discovered and as the project is scoped. You don’t need to report back with a fully formed task list or project plan because that’s impossible. But you do need to have a general idea of where you’d start if so directed.

Some questions to consider at this stage:

  • Are there other teams that are directly needed to help implement this project?
  • Are there other teams at the periphery that will be affected by the project?
  • Is the project self-contained or will other parts of the system be affected?
  • Will the project involve an executive announcement? You need to know how high up the chain your exposure will be.
  • What’s behind the request? Is it a high profile customer under fire? Or just an executive whim?

As you work your initial investigation, document what you experience. Also, never forget the initial goal you believe you were given in the first meeting because you’ll need to confirm this in the next step. You may have to eventually change the goal based on your research and subsequent conversations, but that comes later after new agreements can be made.

Think broadly and long term. Consider technical work, support, documentation, communication, and things that could change in the future. Predicting the future is difficult, obviously, but flush out some scenarios for discussion. Always think as many steps ahead as possible.

Reporting Back

Bring the results of your preliminary investigation into the next meeting so you and the manager are clear about what the original task was and what you’ve done since. This must be in writing. If you are talking about content two weeks after the first conversation without any notes whatsoever you might not be happy where things will lead.

Talk about what you experienced during your investigation. Show your prototype if you’ve done enough work to build one. Show your preliminary task list. Show whatever you have. The more you show the more you can influence the conversation. Continue to ask questions because I guarantee you things will have changed since your last meeting.

Some questions to consider at this stage:

  • Who is the target audience for the project?
  • What is the problem that needs to be solved? Focus on this as much as possible.
  • Is this an existing problem or is this a new opportunity? In other words, are you fixing something that’s broken or are you creating something entirely new?
  • What deadlines are expected?
  • Does this project have a specific end or are you creating an ongoing program to support a series of projects? In either case, what resources will be needed to maintain what gets delivered — code maintenance, testing, program support?
  • Who is leading the project on the technical side? Who has management responsibility? Make sure the chain of command is clear.
  • What resources will be needed to implement a solution and complete the project? Be specific about people skills and infrastructure needs.
  • How often are progress reports expected? What’s the format of the report?
  • Do you need more time to complete the initial investigation? If so, say so and substantiate why.
  • Do you have any ideas to offer based on your preliminary investigations? Are there other ways to approach or solve the problem? Now is the time to assert your expertise.

If everyone agrees that the project should be initiated, continue documenting the issues based on the discussions thus far. It’s important to establish a written timeline of decisions so everyone is clear how the project scope emerged. Maybe start a little wiki page to keep track of all this information so others can contribute. Then the page can grow into a project plan where things can be easily updated.

Repeat

Remember, investigations are iterative. You’ll meet. You’ll investigate. Then you’ll meet again. Then you’ll investigate more. There should be multiple opportunities during this initial phase to document your work and clarify things with management before the project really gets going. Take advantage of this time so you are confident with your position.

So, that’s it. It’s just a little guide to help keep things focused during the early phases of a project when you may be given non-specific instructions that could lead to either a cool new opportunity or a lot of frustration and wasted time. You choose.