#...without being told to refactor the ENTIRE project

[iobartach]

[ryadel]

Visual Studio - ASP.NET Web Site Project vs Web Application Project

When you start a new ASP.NET project in Visual Studio, you have the chance to create a new ASP.NET Web Site project or a ASP.NET Web Application project. This is true since Visual Studio 2008, being it the first VS installment where the ASP.NET Web Application Project template was introduced. What are the differences between these two project templates? Should you choose the ASP.NET Web Site or should you go with the ASP.NET Web Application instead? The answer can be easily inferred from the following article from the official MS knowledge base, which clearly explains the differences between these two project templates and emphasize the pros and cons of each choice: ASP.NET - Difference between Web Site and Web Application Project However, for the sake of convenience, we'll briefly summarize the gist in this post.

ASP.NET Web Site

The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing. If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name, which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be extremely popular. Key factors Provides the same Web project semantics as Visual Studio .NET 2003 Web projects. Has a project file (structure based on project files). Build model - all code in the project is compiled into a single assembly. Supports both IIS and the built-in ASP.NET Development Server. Supports all the features of Visual Studio 2005 (refactoring, generics, etc.) and of ASP.NET 2.0 (master pages, membership and login, site navigation, themes, etc). Using FrontPage Server Extensions (FPSE) are no longer a requirement.

ASP.NET Web Application

The Web Application Project was created as an add-in and now exists as part of SP 1 for Visual Studio 2005. The main differences are the Web Application Project was designed to work similar to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build time. In order to update the project, it must be recompiled and the DLL file published for changes to occur. Another nice feature of the Web Application project is it's much easier to exclude files from the project view. In the Web Site project, each file that you exclude is renamed with an excluded keyword in the filename. In the Web Application Project, the project just keeps track of which files to include/exclude from the project view without renaming them, making things much tidier. Key factors No project file (based on file system). New compilation model (read here or here for more details) Dynamic compilation and working on pages without building entire site on each page view. Supports both IIS and the built-in ASP.NET Development Server. Each page has it's own assembly. Defferent code model (read here for more details).

What should you choose?

If you still got doubts, we strongly suggest to take a look at this excellent post which gives reasons on why to use one and not the other. Here's an excerpt of it: You need to migrate large Visual Studio .NET 2003 applications to VS 2005? Use the Web Application project. You want to open and edit any directory as a Web project without creating a project file? Use Web Site project. You need to add pre-build and post-build steps during compilation? Use Web Application project. You need to build a Web application using multiple Web projects? Use Web Application project. You want to generate one assembly for each page? Use Web Site project. You prefer dynamic compilation and working on pages without building entire site on each page view? Use Web Site project. You prefer single-page code model to code-behind model? Use Web Site project.

Conclusions

That's about it: I hope this post will allow you to have clearer ideas on these two project templates, allowing you to make the choice that best suits your needs.   Read the full article

[topicprinter]

Hey Reddit,​I wrote this post for my blog, but thought you might all find it interesting. Happy to answer any questions!​--​Last week we crossed $15 million in annual recurring revenue (ARR) for ConvertKit, my email marketing company. My original dream was to get to $600,000 in ARR, so I'm pretty thrilled! Over the last six years I've learned and written about quite a few lessons, but it's always fun to reminisce on the highlights, that oddly enough mostly come from the hardest times.1. Focus is everythingIt's fine to start something on the side, but if you want to turn it something real it needs to move to the center of your focus. Years ago I decided to go all in on ConvertKit, moving it from a side project to my only project.Without that decision ConvertKit wouldn't be here today.Anytime someone brags about how many businesses they run I cringe. I'd far rather take one thing and do it really well. I'll leave the serial entrepreneurship for the scattered, the wannabes, or those who are truly far more talented than I am.A friend told me the other day that he was surprised I still only did ConvertKit. At this point we have an incredible team, available capital, and the leverage of an audience. Why not start something else and run it in parallel?Because I know myself.Focus is where I thrive. Focus is where I get results. Focus is everything.2. Choose a nicheChoosing a niche is the easiest advice to give and the hardest advice to take. When you don't have traction, it feels like choosing a niche will exclude the few people who are coming in the door. In reality when we chose "email marketing for professional bloggers" everything changed.Messaging became clear, the product roadmap was trimmed, and the prospect lists practically wrote itself.Without that change—without excluding everyone who didn't fit into the blogger bucket—it would have been incredibly hard to get off the ground.We eventually expanded to "email marketing for creators," which now includes podcasters, actors, YouTubers, authors, artists, musicians, and so many more. Even with growing into that larger audience we are still so much more focused than our competitors who target all small-businesses.3. Use sales to kickstart word-of-mouthWord-of-mouth is the best way to grow a company, but you need traction for the referrals to start. That's where direct sales come in. By choosing a niche, listing out your prospects, and getting in touch directly you no longer have to wait for them to come to you.Each conversation—even though most end in rejection—will teach you so much. At first it's one customer. Then five. Then ten.Immediately you'll notice something crucial: the customers you recruit are higher quality than the ones who just walk in the door. Why would you leave the future of your product up to just anyone who stumbles across what you create?Instead go out and sell to the customers you want. Then ask them for referrals. Finally, when the word-of-mouth referrals kick in, they will be to the right people.4. Do the hard work that doesn't scaleEach sales call would end the same way: "I love what you're doing and I'd love to switch...but it's too much work. Sorry."Ouch. No matter how much convincing I did I wasn't able to overcome that objection. That is until I offered to do the full switch for them for free.That meant getting their account access, moving every form, copying and pasting every sequence email, exporting and importing their subscribers, and so much more! It was terribly unprofitable to do that for a $79/month customer. But early on that was how we got momentum. Every customer matters.So many people told me that wasn't scalable. I needed to use paid ads, SEO, or some other scalable way to acquire customers. That's great if you can make them work, but many can't. So I did the work that no one else was willing to do.John and Patrick Collison famously did this with Stripe. Rather than waiting to follow-up after a promising conversation, they would migrate other startups to Stripe on the spot.Don't wait for the follow-up or have the customer do all the work. Do the hard work that doesn't scale.Today we still offer a free concierge migration for anyone over 5,000 email subscribers. Many of our competitors have copied it and offer it as well.It feels good to make them react to us.5. Find what works and repeat itWebinars were the first scalable growth channel we found that really worked. My first thought was to do those and keep searching for the next thing...but then I realized that we should focus on what's working. We test and iterate like crazy, but then once it pays off we go all in.Over the last three years we've done hundreds of webinars with an incredible number of affiliate partners. They are hard, time consuming, and exhausting. But they work.Run all the experiments. Test. Analyze the data. The when you find something that works be prepared to go all in.6. Building infrastructure to support growth will take far longer than estimatedWe spent our first company retreat fighting fires and rebuilding our server infrastructure. What was supposed to be a time to just connect, plan, and get to know each other turned into an all hands on deck fight to keep our product online.I thought we'd spend nearly all our time building cool new features for customers. But instead the work was in doing what customers care about most: making sure the basics work well. Emails need to send on time and subscriptions need to work flawlessly.There's a lot of software that when it goes down, you just work on something else. Not email marketing. It's core to the entire business and reliability is everything.The infrastructure that was built to support 1,000 customers will break at 10,000. It's crucial to dedicate time to support the growth.7. Funding is optionalRight about now we should be raising a $25 million series A. Or at least that's what our peers are doing. Instead we haven't raised a single dime of outside capital. I put in $5,000 to kick things off, then another $50,000 when I doubled down on ConvertKit.Getting rejected by venture capitalists is one of the best things that's ever happened to me.We built ConvertKit our way, at our pace, and with our values. Every line of code is funded by the creators we serve. I wouldn't have it any other way.8. It's possible with a smaller team than most people thinkToday at ConvertKit we have 38 amazing team members. At $15 million ARR that is nearly $400,000 per team member! A much higher ratio than any of our peers. At this stage 75 employees would be normal.Instead of hiring as quickly as possible to solve every pain, we are deliberate about working on the right things. The constraint requires us to say no, not spread ourselves thin, and only do the highest leverage work.It also means that we can invest in each team member more and carefully craft the culture we want, rather than simply focus on reaching headcount goals.There are always tradeoffs, maybe we could move faster, build more, or support customers better. So we are still striving to find the right balance between team size, efficiency, and total output.9. Culture is everything—and it's not what you thinkWe have so many weird habits as a team at ConvertKit: talking about someone in the third person as if they're not there, long walks in pairs where only one person is allowed to talk, starting meetings by asking, "red, yellow, or green?" and diving directly into the hard conversations.That's because to us culture isn't bean bag chairs and free lunch, but instead an environment where conflict is kind and direct, expectations are clear, and trust is most important.Our version of culture has turned ConvertKit into a place that we all want to come to work.10. Share the profitsThere are two important factors for running ConvertKit as a financially efficient company:Transparent financials. Every dollar spent is visible to the entire company through our open books.Profit sharing. We share more than 50% of the profit in the company with the entire team.The result is that everyone is incentivized to spend money efficiently.We once asked the team: "would you rather go to San Diego or Costa Rica for the next team retreat?"Everyone said Costa Rica.So we did the research and found that Costa Rica would cost about 50% more because of higher housing costs and additional travel logistics. With the complete picture we asked the team again.This time San Diego won by a landslide.That attitude carries over to everyone when they use their company credit card. It's not just the company's money, it's their money. And they spend it accordingly.In the last few years we've distributed over $1,000,000 to the team in profit sharing. All while spending aggressively on growth. That's a number I'm really proud of!11. Always pay your debtsNo, I'm not talking about Game of Thrones, or even financial debt. There's another kind of debt more devastating to software companies: technical debt.The code that worked fine at $15,000 in revenue looks like a joke at $15 million. Not to say you should have spent the time to build it perfectly from the beginning—that's a fools game to try—but instead that every shortcut you take is building more debt. The longer you wait the more interest accrues.We've had to spend a significant of time and money refactoring all of that old code. It's part of scaling. Every software company has to do it, but it would be so frustrating if we didn't expect it and have a plan to pay it back systematically.12. As you grow, your company’s name builds equity. Don’t take that for granted.For years I've wanted to build ConvertKit into a global brand and I thought that meant changing the name to something more brandable. While being focused on this new change I completely missed the trust, care, and love our customers had for the name ConvertKit.You just quietly enjoy the status quo. People only talk about what they want to change. It would be weird to send an email to Patagonia saying, "I really love your name, please don't change it."So when we would receive emails every month from creators who thought ConvertKit was too salesy and they didn't want to be associated with the brand, that wasn't balanced by all the people who had quietly grown to love our name and the brand it represented.Ultimately we decided to stay as ConvertKit, which is a long story that I promise I'll write in full at some point.13. You don’t have to be an asshole to build a successful companyBeing an asshole is one way some entrepreneurs have been able to build big companies. Assholes are often loud about their own success, so we hear about them more than we should. But there are a bunch of good people building exciting companies too. Good people who care for their team, their family, and their customers.Ignore the entrepreneur media.Don’t be an asshole and don’t settle for working for one.14. Surprise launches aren't worth itA surprise launch or release is fun for you… until it isn’t.I love having my Steve Jobs moment by unveiling a new feature to the applause of a crowd. I've done it the last two years at our conference, Craft + Commerce. But behind each of those moments is weeks or months of pushing hard to make a deadline. Trimming the project scope, reprioritizing backlogs, and hoping that everything goes well in the live demo.But that's only part of it. What follows is releasing to customers, which is really painful if you missed the mark on any of your designs, planning, or timelines. That means a ton of tickets in the support queue, frustrated users, and losing confidence in the product.Now we've moved away from launching these big surprises. Instead we work with smaller groups of customers to understand how a new product or change will affect them. Then we use that information to build a smarter launch and rollout plan. A plan that usually involves methodically rolling out to a few features at once.We're still be able to make a splash, but we are able to do it with more confidence and a lot less stress.15. I felt most successful after the hardest decisionsWhile skiing a few weeks ago my friend Anthony asked the group, "do you feel successful?" It was a great question to reflect on while riding the chairlift. I'm always striving to learn more and grow the company, so it's foreign to pause and feel success. That feels like settling when I know I'm capable of more.Overall, I do feel successful, but I was surprised to realize the moments I felt most successful weren't after hitting a major revenue milestone or landing a famous customer.In hindsight, the times I felt most successful were when I leaned on my principles to make the right decision, even though it was incredibly hard.Letting a senior leader go. Rolling back a name change I'd worked on for two years. Restructuring the company.I wrestled with each one. Struggling to have the courage to make the decision I knew was right. But with principles to guide me I could make the decision with confidence.To me success knows that I've built the courage to make the right decision, especially when it is painful and expensive.​--Drop any questions in the comments! Particularly if they relate to software, bootstrapping, and more!

[programmingmadness]

I am currently in school for computer Science, but being honest I am terrible at school. I learn on my own so much better and faster, and I actually have flunked out several times before. I know computer Science is one field that it is possible (not easy, but possible) to get a job without a degree if you can prove you know what you're doing, but I'm also not sure when I can stop saying "I'm learning to program." and start saying, "I'm a programmer. Hire me." How will I know when I'm ready?

Hey!

I don’t know a whole lot about getting a job without a degree, but I’ll try to give you some tips.

Apart from a degree, companies look at the experience an applicant has. This means internships, projects, volunteer work, etc. So what you’ll need to do is build up your résumé. If you have the time, try to get an internship at a software company that’ll let you actually write some code - the more time you’re there, the better. Also try to join a/a few open source projects. This is probably most helpful, as a) your code will be publicly available for people to look at, b) large projects that go on for a longer period of time teach you so much, like refactoring your code once your architecture changes, e.g. Volunteering should be the easiest to actually get (if you’re not too shy to ask). Maybe your local church needs something to organise staff and boom, your CV has one more entry.

I don’t actually know when you’re supposed to be “good enough”. The handy thing with a degree is that at one point, you’re just finished and thus must be “good enough”. On the other hand, companies have told me that they don’t expect graduates to actually know all that they’re looking for, they’re more interested in their ability to learn new things and their basic understanding of computer science principles. I do know, though, that some of the job offers I applied to actually said that you can apply when you’re self-taught, so just keep on trying. If you can, I’d suggest not giving up on school entirely, because if you do make it, you’ll probably have it a lot easier. But you’ll have to decide for yourself if the effort is worth the potential benefit.

All the best of luck to you!