In this break/fix post, I’m going to show you how to fix a specific error that I was getting in an Azure DevOps pipeline during a dotnet publish command that stated “Problem starting the plugin ‘CredentialProvider.Microsoft'”.
Here’s the full error message:
C:\Program Files\dotnet\sdk\5.0.201\NuGet.targets(131,5): error : Problem starting the plugin 'C:\Users\VssAdministrator\.nuget\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll'. Plugin 'CredentialProvider.Microsoft' failed within 5.256 seconds with exit code -1.
A credential problem?
It was only failing on one of three project publishes and on the NuGet portion of the publish command. My first thought was that the credentials might be incorrect. We recently had a developer leave and I thought that potentially something was set up with his credentials and was revoked. I double-checked the service connections in Azure DevOps and everything looked to be ok.
A .NET CLI version upgrade?
I then noticed that Azure DevOps was using Microsoft Build Engine version 16.9 as opposed to my local version of 16.8. I upgraded locally, and couldn’t reproduce the issue. Everything was great there.
A timeout issue? (yes)
This is when I took a closer look at the error message below.
C:\Program Files\dotnet\sdk\5.0.201\NuGet.targets(131,5): error : Problem starting the plugin 'C:\Users\VssAdministrator\.nuget\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll'. Plugin 'CredentialProvider.Microsoft' failed within 5.256 seconds with exit code -1.
As it turns out, NuGet defaults to a 5-second timeout, which very closely aligns with the 5.256 timeframe of the error. Doing some more investigating, I found you can increase this timeout by setting an environment variable. I decided to increase the timeout from 5 to 20 seconds in the azure-pipelines.yaml and guess what? It worked!
# in your azure-pipelines.yaml
variables:
- name: NUGET.PLUGIN.HANDSHAKE.TIMEOUT.IN.SECONDS
value: 20
- name: NUGET.PLUGIN.REQUEST.TIMEOUT.IN.SECONDS
value: 20
The above tells the running pipeline to inject the following environment variables during the run:
Maybe it was the Azure DevOps upgrade of the build tools to 16.9 made Azure Pipelines get just slow enough to push it past the 5-second timeout for the CredentialProvider.Microsoft plugin.
We’re also connecting to 3 external feeds during this project, so it’s more than the average project that may only connect to the main NuGet feed.
Hopefully, this gives you some insight into the problem and a quick solution to save you a few hours. On to the next fire!
My current team is the longest I’ve ever been with an organization (other than my own freelancing business), almost 5 years. Over the years the needs, motivators, situations, and lives of people within an organization can and will change. It’s the nature of life.
There are obvious ways to reduce turnover, like avoiding burnout of your team, compensating people well, providing adequate training and opportunities, and aligning individuals with meaningful work. Even with all of these things, and no matter how much people say it, no one is guaranteed to be around forever – or even the next year.
Twice now in my career, I have had someone say to me “I don’t plan on going anywhere” and then offer their two-weeks notice within 3 months’ time. And that’s ok.
We should celebrate when someone gets an opportunity to take a chance and chase a dream, or grow, or get a new opportunity.
What makes a difference at these points, is that the organizations and teams that expected developers to leave fare far better than those that do not.
Why should you expect developers to leave?
You have probably heard the phrase: “What if ______ gets hit by a bus?”.
This effectively means what if something unforeseen happens and the person is no longer with the organization. This phrase actually causes a huge problem in a lot of teams. Getting hit by a bus is a rare event. When we pause to ask if someone will not be with us, we phrase it and think about it as if it is a rare occurrence. In reality, in January 2020, the average tenure for a Computer Science/Math employee was only 3.9 years. This means that not only will someone leave on your team, it’s probably going to occur sooner than you think.
Why does expecting developers to leave help them not leave?
When we expect people to leave, our priorities change. We switch from “I can always just ask” to “Make sure we can be successful without you”.
When we change the culture to focusing on simplifying, documenting the “why”, and ensuring others can easily maintain code without the original author, we inherently reduce complexity. When we reduce complexity and the baseline requirement for understanding code and systems, we free up our minds to be more creative in other places.
This benefits teams not just when the developer leaves, but also helps free that person from questions when new developers join the project without the extra hand-holding.
Assuming devs will leave helps us unlock the full potential of our teams in creating real value for customers, both faster and with more brain bandwidth to build better solutions.
Ten years ago I thought I had to choose between good opportunities as a software developer in larger cities or living where I actually wanted to live (a much smaller town).
I spent the next decade building a personal brand, a freelancing business, side projects, a local and online developer community, and more to create the career I wanted and live where I wanted.
First, what does Success Syndrome look like for a software developer? It’s when you become successful at something and then subsequently become overwhelmed. This can happen if you get a promotion, become the “go-to” person for something, or take on new opportunities due to your new recognition.
You started out just wanting to be helpful or useful, and now you’re overwhelmed and can’t keep up.
If left unchecked, Success Syndrome can actually lead to burnout and potentially depression. This can be especially bad if you pin all your hopes on productivity or accomplishments fulfilling you.
Let me just say, though, that “Success Syndrome” is an indicator you’re doing something right. It means you’ve built trust, relationships, knowledge, and the start of a personal brand within your workplace or community. I’m not saying that that Success Syndrome is all good, but I am saying that the burnout is what the real issue is here. And burnout comes particularly fast when you have to field questions from peers from the former position, as well as from the new position during promotions while also trying to complete your regular developer work.
One useful observation is that many of these questions tend to be the same.
“Hey Ryan, how do you set up X.”
“Hey Ryan, you’re good with JavaScript, what framework should I use for this project we have coming up.”
“I got this error, what do I need to install again?”
Requests from peers or others can usually be boiled down to a StackOverflow-style question and answer pair, which is (and here’s the secret) a content gold mine.
If you’re experiencing burnout due to a large number of questions from peers that you get over and over from different people, and particularly if they aren’t NDA-based (which project-specific questions probably are, so check with your manager first) then what you need is to write those questions down!
Often times if you’re answering questions like this and they aren’t in blog-form, posted on your personal site, then you should start one and get to writing!
If you’re experiencing Success Syndrome, it’s likely that you feel good helping others and answering questions, but if they become repetitive and you’re asked something a few times, write an article and point people to it! It’ll save you time and also allow others on the internet to find it.
Multiple people asking the same thing also validates there is an audience for the question.
Questions from peers at work that might have project-specific answers, particularly ones over email, are ideal candidates to write up in a wiki or a ReadMe.md file right inside your repository. Then, once you have things there, send a link to it in email to them. Other team members will be glad you did.
We’ve all complained about technical debt and legacy code, but it’s not all bad.
When I was a junior dev, I would complain about lots of existing legacy code that I encountered. I ran into a lot of it doing contract consulting work. This wasn’t just the obviously bad stuff, either, like finding some homegrown ORM using non-parameterized SQL queries being read from XML files. 😬
I complained about the little things. Like using a loop or if statement that wasn’t the most optimal, or copied code, or someone not using some library I thought they should be using. Honestly, I still fight that temptation sometimes. It took a few projects to really get perspective on technical debt, where it comes from, and how to appreciate it.
Often, technical debt sold the software to allow you to have a job.
Think of the times you had to add technical debt. It was likely to hit a deadline or meet some pressing customer need. Those pressing sprints were typically when a high-paying, critical customer needed something. The key to effectively working with technical debt is don’t become over-leveraged.
Strategic technical debt can bring you key wins at times that you can pay back later, but if you become over-leveraged with technical debt, and don’t pay it down, you eventually come to a point where you’re unable to move forward at any reasonable pace.
Sometimes code isn’t optimal but increased MRR (Monthly Recurring Revenue) just enough to allow for hiring a new person – you.
Why are rules, quotes about rules, punishments for broken rules everywhere?
When my daughter asks me what the rules are, she’s probably not asking what they are so that she can follow them. She’s asking so she knows how to get around them. What are the boundaries that I can operate in and what loopholes are there?
Rules help us to define certain boundaries and the operating procedure of how we interact and behave with each other, but rules aren’t actually the main thing.
In addition to explicit rules, there are unspoken rules, which sometimes eventually become explicit, spoken rules. Some examples include:
“Don’t steal.”
”Meet your deadlines.”
“Test your code.”
“Don’t tie your brother’s leg to the dog’s leg.” (A great example of an unspoken rule that recently became an explicit rule in our house)
Some rules are soft and some are hard. But they usually have one thing in common – they support and maintain relationships between people. Rules are contracts for how we can respect and serve others.
You may think that you need to create more rules to improve the culture, but often you don’t. You’re doing a disservice to people when rules are used as a replacement for genuine relationships.
While you can always focus on more rules, more punishments, more restrictions, it can never replace the heart of what we all want when we create and enforce rules – trust, honor, and respect.
Use formal rules to improve the how as opposed to the why.
When you try and improve the culture of an organization, and you’re looking to add more rules – stop and ask if the rules are actually necessary. They might be, but often you can get a better and more lasting result by stopping, listening, and simply improving the relationship with others. In doing this, we can avoid some (many) explicit rules altogether.
Moving the cheese is often frowned upon, but is it actually bad?
This past year I quit coffee.
Not necessarily on purpose. I actually love coffee. Though, when you get up to three cups per day, it’s probably a good idea to cut back, so I needed to.
So what changed? My wife rearranged the kitchen.
She “moved the cheese”.
“Moving the cheese” has a generally negative connotation, but the moving part is given more emphasis than the most important part – the behavior that the environment change creates.
The coffee pot, the scoop, the coffee, the water, the mugs all moved to different parts of the kitchen. No longer were they right next to each other, taking seconds to complete the coffee-making task.
When each of these items became further apart, it increased the friction of making a cup of coffee during the day. They didn’t move by much. It’s only an additional few steps, but it was enough to completely stop making coffee at all.
Sometimes we think that our habits are too hard to change. Even impossible. But that’s not true.
We change every single day. In fact, our brains want to change to become more adapted to our environment.
Did I complain? Yes.
Did my behavior change? Yes.
Was it good for me? Probably Yes.
If you want yourself, your team, or your users to change their behavior, change the environment, and let them adapt naturally. Don’t focus on if the cheese moved; focus on what behavioral changes will come as a result.It might be uncomfortable, there may be complaints, but we were made to adapt, and sometimes, it’s good for us.
I’ve been writing in various forms publicly for about 12 years now.
The majority of that has either been guest blogs or on my own site.
I do it partly to organize my thoughts and solidify my understanding of topics and observations, and partly to get better at one of the most important ways to communicate – writing.
Over the years my personal site as moved several times, but each time I’ve moved it, the only regrets that I’ve ever had were moving the content to a place where I didn’t have control of 4 things:
The freedom to control what I write.
The freedom of who has access to what I write.
The ability to set a custom domain.
Setup of 301 redirects.
That last one is probably only important when you can’t decide on your slug and change it over the years. 😅
Medium was a great writing and publishing experience for a few years. Then they removed custom domains and added paywalls.
Substack’s brilliance is that it provides a simple publishing platform when the most important thing for you to do is write. In my review of this year I realized that what I really want to do is write.
And so, that’s what I’m doing.
Just…not here on Substack. (I didn’t just pull a clickbait, did I? 😬)
To subscribe via email, visit my website at https://ryanhayes.net and use the sign-up form for both regular articles and other updates.
I’ll be talking all about what I learn in building cultures of innovation in Fortune 500 enterprises, remotely working in the mountains of rural America with high-growth small-town tech startups, and the principles that I learn that help make a difference in both.
Also, I’d love to learn more about you and what you’re interested in hearing about, so say hi!
January was filled with business trips, hotels, planes, and gatherings. I remember seeing a couple coming from Europe in the Atlanta airport getting off a plane wearing masks. It was the first time I ever really stopped and thought about catching anything serious in a long time. The Coronavirus was the only thing on the news as I sat eating my usual turkey and cheese sandwich from the Boar’s Head Cafe while waiting to catch my flight. I remember thinking about when I picked up H1N1 back in 2009 while I was living in DC and was probably the sickest I’ve ever been. That flu was a bad time.
If one thing’s clear, it’s that this year has given me more perspective and made me more grateful for my family and the little things in life.
To the cloud!
As everything shut down on March 15th. My focus switched to helping my organization transition to fully remote and my local community’s businesses transition to mobile ordering, curbside pickup, and in general just how in the world to use technology to not go out of business. The companies who had made the transition to allowing for curbside pickup before the pandemic were weathering ok, and the ones who thought everything would blow over continued to decline. It hurts my heart to see so many businesses I loved visiting shutting their doors. The virus has taken both lives and livelihoods, and I’ve felt fortunate to be in a line of work that can basically do 100% of everything from home.
Volunteer Work Pivots
Last year, I joined the executive board of FoundersForge, a local non-profit focused on helping entrepreneurs in NorthEast Tennessee build scalable, high-growth businesses. We mostly run in-person events, and that completely changed. We re-focused our efforts into directly calling and working with entrepreneurs and helping them get connected with the resources they need. We planned a huge 2021 roadmap that I’m so excited about. Plus, we recently raised enough money to execute a good chunk of those plans. Using business as a way to do good in the world is something I’m passionate about, and working with such a great team here who shares that vision is truly inspiring.
TriDev, the developer meetup that Jeff Rainey and I have run for years, went full-remote. At first, we had about the same number of in-person people, but Zoom fatigue quickly set in. Even I feel it. After 10+ years of screencasts and virtual meetings, at the end of the day, I just want to go outside. I’m fortunate to live in the mountains where we have plenty of places to go, but my outdoor time has even gone down this year. RIP my Strava premium account.
Last Year as a Microsoft MVP
I’m grateful to have been awarded a Microsoft MVP award nine times. This year was my last and was bittersweet, but the program needed some fresh blood and I’ve become less directly invested in Microsoft-specific tech in recent years as the web has spread out more and I use a wider variety of tech to build software. Nine is the number of seasons Seinfeld had, and the number of years the Beatles were together, so I guess it seems like a good time to end it anyway. 😅 I’ll miss the MVP Summits, though (the in-person ones), and seeing everyone more frequently.
#IntrapreneurshipLife
I don’t speak for the org I work at all here, in any stretch of the imagination. Opinions are my own, etc.
However.
I’m incredibly proud of a new thing we built this year.
I’m a big believer that the principles that make a great startup a great startup are the same principles that make large, enterprise-size organizations great. Not least of these principles is laser-focus on bringing value to customers with everything you do.
Our org builds software for K-12 cafeterias, among other things, and COVID-19 changed the expected behavior of almost every single one of our users. As part of the work I did internally, we went from brainstorm to idea, to prototype, to shipped product with paying customers in about 6 months.
We essentially built a Doordash for K-12 schools called Heartland Meal Orders.
While doing so, we laid the groundwork for a new design system, built with Figma and Storybook and React components, and I’ve internally joined the design community of practice. While I’ve traditionally been a backend/API developer, designing and building great user interfaces are critically important and expected by the average person.
This leads to…
Things I Intentionally Learned
Every year, I pick a couple of technologies and go deep.
CSS (architecture and systems)
I’ve always known enough CSS to get the job done. Mostly based completely on Bootstrap or Foundation with everything overriding those controls. This has always served me and my teams well starting out, until we wanted to do anything custom and then everything fell apart trying to keep up with the Bootstrap upgrades. Custom CSS has its own problems, but doing it right, particularly when you have a design spec and are using a modern, component-based framework like React or Vue, it pays significant dividends later in your ability to reuse code and execute on changes quickly.
The new project we built at work had a near completely custom design, didn’t support IE11, and I was the font-end lead on the project. It was a great opportunity to really solidify my front-end skills. Parts use CSS Grid, but the majority is Flexbox. Honestly as much as CSS Grid gets talked about, Flexbox is the real workhorse of the web, and I have a deep understanding of it and edge cases now.
CosmosDB
I’ve only ever really used relational databases for apps. While I’ve used Redis for caching, and MongoDB for side projects in the past (does Firebase count in non-production toy projects?), I’ve never used [shipped] them as the primary database for a project – until now.
CosmosDB has its warts. While it touts a MongoDB API and others, only the SQL API is truly ready for a production application. It has a steep learning curve, and many foot-guns that can cost you thousands of dollars in Azure fees. It’s dangerous. But it’s fast.
Wow, is it fast.
The speed is yours to lose and having shipped a fully production, customer-paying app on CosmosDB, it’s been fun to see the extremes of the benefits and the dangers of this technology.
Next.js and GraphQL
I tend to tell new developers that the first thing they should do is start a personal website, since you can do one very important thing: Learn a technology in context from start to finish. From git to builds, to staging, to prod, to monitoring, to performance. You can learn everything and build something in production with real users and real feedback. And it’s all yours.
This year I rebuilt my website (previously Gatsby) in Next.js. I hated GraphQL in the context of Gatsby, and Next.js gave me routing conventions and more flexibility over where the content was coming from.
I went from markdown (which ended up being GraphQL on top…again), to Contentful (also GraphQL), and finally to WordPress GraphQL, since my content has all of its history there. It was fun to see all that Next.js has to offer, and what a powerful frontend platform it is for building sites and apps.
Redwood.js
I spent a big part of mid-year’s free time building a side-project in Redwood.js. Redwood is trying to be the modern version of Rails, and adding conventions and glue on top of Prisma, Node, React, etc, to make a single platform. I love the direction, but it’s built in JS instead of TypeScript, which means that there was no intellisense and type support for a very long time. It’s still coming, and I ended up spending an inordinate amount of time writing tests just for types and in the forums. I eventually gave up and have been looking at Blitz.js for the new year.
Bullet Journaling
This is probably the biggest thing I started this year that I’m carrying into 2021. Bullet Journaling is a daily practice.
BuJo is part task management, part diary, part note-taking, part art notebook, etc. Most importantly bullet journaling is intentionally slow. So much of my life had become fast and fleeting. I was becoming forgetful. Not that I couldn’t remember things. I have a decent memory. It’s just that I wasn’t remembering, or doing, the right things.
The act of pen and paper note-taking has forced me to remember and focus on what’s important. Since my hand will cramp if I write too much, I only use my pen strokes for the most important things. It’s helped me focus on the things that truly matter. I attribute the majority of productivity, clarity, and not spiraling into a mental health disaster this year on intentionally removing the screens in the morning and key times of the day, and being mindful of the gift that time is.
A side benefit has been that it’s made articles like this, where I review what I’ve done much easier. It feels sometimes like the year just goes by and I don’t accomplish much, but writing down the things I learn, the takeaways of the seemingly tossed away side projects, the small joys of time with my kids, and having a record to pass to them someday puts more life in my years.
The Year of the Mac
Ok, I promise that it’s not where I’m not an MVP anymore, but I do feel like I have more freedom to say this, but I switched to a Macbook Pro this year. I still use Windows and Visual Studio for some things I can’t get away from (dashboards and reports that require full framework .NET and Visual Studio proper for a report builder). Everything else, though is all Mac OS for day job work.
Visual Studio Code with the right plugins is a joy to use, and as much as WSL/WSL 2 has overcome so many of the npm install type of Windows-only errors there ends up just being different, more esoteric errors to replace them. .NET 5+ and of course anything Node.js and more simply work better, faster, and more consistently on Mac OS.
I hate it, but it’s true for me.
In addition, for the same reason Mac folks used to have a Windows VM to test for the IE users, I now need access to a Mac to test for weird Safari bugs. MS Edge is my daily browser driver, but with a Mac I can get in and out without much fuss or additional VMs tying up my machine. I still own a desktop PC for personal code work and any Twitch/Video work, but everything else now is either my iPad Pro or Mac.
Mentorship
I’m a big believer in mentorship and freely giving of the wisdom we collect over the years. Life has some curveballs, and it’s important to pass on what we’ve learned, for better or worse, to the next generation.
At work, we have a program I’m a part of called “Future Leaders”. It’s a two-year executive leadership mentor program, where you’re paired with a VP or higher to learn the ins and outs of the business and help train you to be a better leader. The title is kind of a misnomer, since almost is everyone is a leader for something, whether we feel like it or not. But it’s been insightful being able to see behind the scenes of how things work during a year like 2020.
The biggest takeaway from this is that openness has been so important for me to be able to make good decisions for the business and also feel like my work matters (there should always be a way to trace back your work to a “why does this matter?”). In closed-communication organizations, it’s hard sometimes to understand where particular stories or tasks fit into the bigger picture, and understanding the business side of the technical work helps flesh out the “why”.
Onward
As 2021 rolls in, and a vaccine is on the horizon, I’m excited for the new year as we slowly move back to some form of normal that involves people. Even an introvert like me can’t wait to see people and regain the ability to just go sit in a freezing cold Starbucks and listen to the hum of life and overly loud indie music.
A hackathon is a set time frame, usually 24 hours, where teams build something. They can either be for fun or competitive. For-fun or non-competitive hackathons often revolve around flexing creative muscles while building community. Many can even be for the benefit of non-profits or to contribute to open-source software. Organizations like GiveCamp and Startup Weekend help organize large hackathons worldwide and make it easy for developers to get involved. (Running a GiveCamp is a great way to flex your leadership skills).
At the end of the time limit, they present their creations to an audience. Depending on the types of hackathons, the winners can take home fantastic prizes, like funding for their idea, credits toward services, or cold, hard cash.
The primary goals are to get people out of their comfort zones, try new things, and build something incredible within a set of constraints. You’ll come to notice that not all hackathons are created equal, so understanding the context of the one you are entering is of paramount importance.
There is a formula
What if I told you there’s a formula for winning hackathons?
While every hackathon is different, and the strategy in how you prepare, build, and present is different. In this article, the definition of winning is taking home first place or a top prize, but there are other incredible benefits of hackathon participation that can be equally important. You can "win" by becoming better as a developer or entrepreneur. You can "win" by networking with others. Keep that in mind as we start with the first step – preparing for the hackathon.
Know the rules
The first and the most non-negotiable rule of winning a hackathon is to know the rules. You don’t have a shot if you are disqualified from the competition or fail to meet the requirements. If the rules state that you must use a specific service or technology, you must use that technology. If there is a requirement for a certain number of teammates, then meet those requirements. This leads to the next softer rule of knowing the audience.
Know the audience
Knowing the audience helps give your team and your product focus. If the hackathon is based around high innovation, then a to-do like application will likely not win. If the theme is "hack for non-profits," then a robotics project based on drones will probably not help if the non-profits present are lower-tech office workers who just need a new website. Keep in mind who is attending, the hackathon theme, and what the people attending are looking for. This is particularly important for winning the "people’s choice" awards where the audience votes.
Know the judges
The win and the loss are ultimately in the hands of the judges. When planning your idea, it’s crucial to know who the judges will be, their industries, and their background. Each judge will bring with them biases, personal interests, and philosophies of what a winning project will look like.
An angel investor is likely highly focused on ROI and innovation. What would the market look like, and how much could this potentially be worth?
A judge with a marketing or sales background will likely be excited by things that show well.
If a particular judge has a clear stance against the continued increase in mass surveillance technology will likely not vote for you if your project requires a camera in their bedroom.
The key here is to find hard-negative biases to avoid while looking for a project idea that hits the excitement button in some way for each judge.
The Team and The Idea
"If you want to go fast, go alone. If you want to go far, go together." is a quote that applies so well during hackathons. When selecting a team, the main tradeoff is that the fewer people you have, the faster you can pivot and move, while each additional person adds communication overhead. Additionally, you want to balance something that is both ambitious and doable. Understaff an idea, and you won’t complete it. Overstaff a plan, and it leaves someone sitting on their hands at best, or at worst, will slow you down.
It’s best to keep the team small, particularly before you solidify an idea. Two or three people total is best. These key individuals are your "founders." They are both idea machines AND can execute. If the work for the idea can be evenly distributed between the three, then continue with the team.
If the idea is ambitious enough to need more people, then you’re at your first crossroad to "go far." You must stop and determine if the execution you are planning can support more people and decide where the "snap points" or interfaces will be.
As developers, we’re familiar with the concept of an interface. It’s a contract between two types – a bridge that allows developers to build pieces of a program, totally isolated from each other, and have some semblance of a guarantee that the two will work together. This concept and construct is the key to building larger projects in a shorter amount of time. The most effective software leaders know how to use interfaces to effectively divide and parallelize work, and it’s a vital skill to have if you intend to ramp team size.
In one hackathon, my team won by building a universal search for an existing application. It was similar to how the Windows key works on Windows or Command + Space works on Mac OS. We started with a team of 3, where we created an interface for services to search different parts of the program. One person built a service for the navigation and menus, and another the user search service, and a third built the UI. This division of work allowed us to agree on a common language between the services and, once complete, gave us the unhindered freedom to work in parallel for the rest of the time. Once we realized this, we recruited two more people to help build other services. Since an interface was in place, we were able to parallelize that work as well.
Look for ideas that have parts that can be broken off. This gives you the power to be more efficient in building a real demo of your design or product and ultimately gives you the edge over the competition whose idea is less complete. Ideas are cheap. Execution is everything.
The Execution
The execution.
The demo.
The prototype.
This is where the fun begins. It can generally be a hectic segment. If you did your due diligence in planning and team building beforehand, your goal should be clear. Break up the work and start building. Pivots and questions are sometimes inevitable. If you see that you are running into unforeseen issues, sometimes it’s best to pivot in a new direction, or at least mock a particular service or part and note the assumption.
Some hackathons, such as Startup Weekend, have designated business and technical mentors. Keep in mind any resources available to you during the hackathon and take advantage of them if appropriate (my #1 tip would be any free snacks, of course).
For picking technologies to use, some people try new tech to learn. If your intent is to win, use safe and known languages and technologies for core parts of your prototype. Only use new or unknown tech for required pieces that relate to hackathon rules, if possible. If rules say no code should be written until the competition starts (most do), then think about the code beforehand. What might it look like? Many times you imagine what structures and integrations will generally look like before you code, so run things through in your head to ensure a clean implementation.
The Presentation
The final presentation is critical. It can make up for execution missteps, and it can lose the competition for an incredibly well-built prototype.
First, choose the best presenter on the team, who is most comfortable on stage. This isn’t always the leader.
Next, craft the story. Think of the judges and the audience. What ideas are they interested in, and what stories can you tell during the demo that they will connect with? Keep in mind the original goal of the hackathon. If it’s a startup or business-focused hackathon, then be sure to include all the essential numbers. Include data about the market, ROI, relevant competitors, etc.
Finally, be sure to nail the ending. Have a final slide or come back to the most important questions and remind the judges and audience of what they just saw. Why is this the problem to solve? Why now? Why is this the right solution and not something else, or nothing at all (many times in business we aren’t fighting against competitors, we’re fighting against customers or people doing nothing)?
In Conclusion
Hackathons are incredibly rewarding and pack incredible amounts of experience and learning into a small amount of time. I recommend everyone participating in one at some point in their career (the earlier, the better). Have you participated in a hackathon? If so, what helped you get the edge over the competition? Or, what did you do that you might do differently in the future? Leave a note in the comments and let me know.
Visual Studio is a fantastic IDE (and free for individual use)! It’s been so great that they’ve added modern web dev support in recent years for things like React, Webpack, and more. In addition, Visual Studio’s installer has an option to install Node.js as part of its regular installation in order to support the npm task runners that are built in. However, I ran into an issue I updated Node.js outside of Visual Studio , but since Visual Studio uses its own install that is separate from any outside installation, you can potentially run into a node_modules package dependency issue where one version of npm installs a package (which makes it rely on that version of Node/npm), and then you can’t run commands in the other version (they break).
Specifically, I had an issue with node-sass and windows bindings. The solution was to point Visual Studio to the version of Node.JS that I had already set up externally to Visual Studio. Here’s how to synchronize them:
Step 1: Find the Node.js install location
First, find the Node.js installation that you use on the command line. By default, Node.js installs to C:\Program Files\nodejs. Unless you picked a custom installation directory when you initially installed Node.js, this is likely the path you’ll use.
Once you’ve found the installation directory, copy that directory path to your clipboard for a future step.
Step 2: Configure Visual Studio
Let’s setup up Visual Studio to point to the real Node.js
Note: These instructions work on Visual Studio 2015, 2017, 2019, and probably future versions as well.
To configure Visual Studio to use a different version of Node.js, first open Visual Studio and navigate to Tools > Options.
In this dialog, go to Projects and Solutions > External Web Tools to open the dialog that manages all of the 3rd party tools used within Visual Studio. This is where Visual Studio is configured to point to a specific version of Node.js.
Add an entry at the top to the path to the Node.js directory to force Visual Studio to use that version instead.
Using the Windows PATH Instead
If you’re making this change, you probably notice that you can also move the $(PATH) option up to tell Visual Studio to look at the PATH environment variable to determine where it should look for node or other command line tools. This is probably what you want globally if you’re someone who is comfortable with the command line and understand the implications.
In general it seems that Visual Studio tries to isolate itself and the tools it uses from both other installs of Visual Studio and anything else that may cause issue with it. In general, Visual Studio developers have not traditionally had to touch the command line much, so this makes sense historically, but modern web applications require a different approach.
Managing switching the Node.js Version using Powershell
Another issue that might arise due to using the $(PATH) is that you might have projects that use different versions of Node.js. For example one might use Node.js 8.x.x, while another uses 10.x.x. In this case you might want to use Node Version Manager, or "NVM" as it’s called, to switch versions on the command line in powershell.
You can use NVM to switch versions of Node.js yourself on the command line, or use it to read the package.json file’s "Engine" property, and sets the appropriate version. If the version isn’t available it can even silently install the appropriate Node.js version. This is helpful in many situations, and can be included in an MSBuild task if needed to swap the version when you hit the "Play" button to the correct version, or as a step in your CI/CD build process.
Wrapping Up
And that’s it! Now you’re all synced up! Having two separate installs is really confusing. If you’re starting out with JUST the VS Node.js version, you’ll eventually come to a point where you may update node.js by installing it outside VS, causing it to get out of sync anyway. If you’re a veteran to Node.js, then you’re already using Node outside of Visual Studio and will need to do this anyway. It seems like there should be better documentation or indicators to show what version VS is using so this is more apparent.
Hope that helped. Did this fix it for you? Do you have a better way of keeping this in sync or a plugin/tool to help out? Let us know in the comments!
