As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I recently came up with an idea for a simulation/strategy game. I've been sketching out a lot of my ideas on paper about the game mechanics as well as have a few of the basic classes and objects working. (I'm writing this in C# using XNA).
One thing that is painfully obvious to me though is that I am not a graphic artist and trying to get anything graphical programmed right now is frustrating me. One thought that came to mind was trying to make the entire game work off the text console first. I remember spending hundreds of hours playing Zork and Hack as a kid and the majority of my game element ideas don't require real time sprite animations to work.
So my question to the community here is should I try to maintain my enthusiasm for concept by focusing on getting it to simply work in a text base mode first and then regroup on giving it a pretty graphical interface?
OR
Tackle the graphical interface hill at the same time I'm trying to flush out my idea?
During the course of writing this question I think I answered it for myself, but I would love to hear thoughts from people.
I think you have the right idea based on your description of the game. If you separate your concerns then you can implement a lot of the business logic first. Think of it like an MVC application. You can leave your view to be implemented later; just provide a layer that interfaces with your business logic, that your view can use.
This way it doesn't matter what your view is (text-based or graphics). You can just pass metadata up to the view, and the view will decide how to render it.
So I would say that your idea is good. Start off with the business logic and a text-based view. That way you can get your concepts and ideas fleshed out and also decide what kind of data to pass up to the view. Remember one thing though - you have to be extremely careful at this stage to not let assumptions about the view leak into your business layer. So you should code your business layer and associated interface to the view, as if you have no idea what the view is going to be. What I mean is, since you are starting with a text-based interface, don't make coding decisions that tie you to that particular implementation.
Once you have everything fleshed out, you can start learning graphics and slowly start your graphics layer.
Of course, this approach (MVC) may not work in all situations, especially when your view is time critical. For more information, take a look at these Stackoverflow questions:
Is the MVC design pattern used in commercial computer games.
Best practices when Designing iPhone Game with MVC
Game framework architecture - view components or MVC
I just want to be clear that I'm not advocating an MVC pattern for your game -- I just want to emphasize separation of concern so that it is easy for you to swap your view without doing significant refactoring.
A game is a complicated project which can be divided into many compartments. These may be actual module (e.g., a GUI renderer or a communications manager), or they may be more theoretical or logical, such as the "game design".
While all of these parts work together - preferably in harmony - to bring out the actual game, each of them also stands by itself. As such, it is always a good direction to divide & conquer. If you are confident about your idea, then by all means go ahead and implement it in the simplest form possible, which would probably be a console application.
However, you do need to keep in mind that while you can start by developing each module separately, eventually you will need to take into account how these parts will work together. This will inherently impact your modules design. For example, you may find out that your game logic is working beautifully, but you have no way of letting the user actually doing a certain step in terms of UI. Playability is one of the most important features of a game, and your UI may even dictate some game logic. This concept contradicts the golden rule of separating the UI from the logic - but like I stated, games are complicated, and for the final product you often find yourself bending some rules. Games are different than other projects - scalability is not an issue. Maintainability is important but will be sacrificed if you need that extra CPU juice... and so on.
Make an UI. Keep the graphics simple (Paint) and focus on usability. Then release your game as open source and someone else will create nice graphics and a cool UI.
My advice: almost no software nowadays can be done single-handed.
Try to sketch out your ideas, post somewhere, find more people interested, assemble a group, and get your hands dirty.
If your idea is truly good, you'll find more team members that can fill your lack of expertise on the other areas needed.
You can try to find people on the web, starting something like an open-source project, or you can try finding an investor, that can inject money on your business and you'll be able to hire specialized people.
If I were you, I would create a text-based command line interface first. Then, if you decide to make an actual GUI, you can just have the GUI automate the command line game, so you don't have to write the game logic twice. Many tools will use this approach. Someone will create, for example, a command line defragmentation tool and then someone will create a GUI "wrapper" for the tool. Sort of like what Nethack did.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 months ago.
Improve this question
I'm working on a game reimplementation in Unity, but I want the bulk of the code that deals with the game's resources to be engine agnostic so that tools can be easily made to mod the game by just dropping them into a new C# project, excluding all Unity specific code.
To achieve this, I have a few singletons that handle implementations for certain things. For example, when loading a PNG texture the engine agnostic code calls a texture factory singleton that has the Unity-specific PNG loading code.
The problem now is, I'm about to start working on loading models which normally would involve Unity's Vector3, Mesh, etc. classes, but since I want to be engine agnostic I have to use some kind of abstraction for these or some kind of marshaling.
The obvious way to do it with Vector3, for example, would be to create a new Vector3 class that resembles Unity's Vector3, and simply translate them to Unity's Vector3 by creating the Unity version with the same XYZ values, one by one. The issue is that I'm going to have large arrays of these, so this sounds really inefficient.
I've already tried this with Color32/Color for texture generation code and it was way too slow, so I'm stuck coming up with a solution.
I've thought of just having a factory singleton that creates UnityEngine Vector3 classes and make the engine agnostic code simply expect "object" types rather than any specific type, but I feel this would be way too messy to deal with. Might really be the best solution for performance, though.
Would appreciate any advice!
You won't like the answer: don't do it.
Just write it in Unity-specific code. Don't expect copy-paste and don't create 20 layers to make some sort of magical abstract transformation mechanism. Regardless of the language, this is a serious design vice. First, let's consider you switch from one C# to "Unity C#" (there is some discussion here, but I won't get into it as it's not relevant now). Unity has different code-design and architecture paradigms and concepts. They are slightly different, from say, a web app, server middleware code or even a desktop C# program. Even if you could make wrappers, the work behind it would be hard, not just to "translate", but also to match one paradigm to another. It's like writing C for DOS and then making a layer in Windows 11. Sure, it's the same language, but the concepts are different (I am not bringing up the OS API here).
Now, let's assume you have a C++ game. If you'll switch to C# (for example using intermediate libraries), then, let's say you want to switch to C++ again in 10 years. The C++ standard now is so different than C++99 that those that took a break these 25 years might consider it a new language or extension. And what would happen if you did want to switch to UnrealEngine? Would you wrap over the C# that wraps over the old code?
In the end, it sounds like this is what you'll end up anyway: video classes over the old code and video classes over unity's code, then a translation layer, same for grapics, audio, maths... in the end it will almost be like making a new engine.
Apart from coding errors that might appear, imagine doing maintenance on it. And not by you, but by a team. A new team (if people leave and you get new guys in). There are so many factors in it, that the whole effort isn't justified.
Migration is the best solution, just write code as close-to-native (from the engine's point of view - by this I don't mean asm or whatnot, I mean, as close as what the engine expects it to be like, instead of some magical wrappers or abstraction layer). You'll skip the performance hit of abstraction (because trust me, adding one, two, 500 hundred layers of some magical code will add memory overhead and possibly even CPU overhead) and you might even find some code that can be simplified. Unity has loads of native 5-lines-of-code solutions that can reduce code. Even assets (paid or free) that feature extended utilities, plugins or common code helpers.
P.S. you might hear some crazy workarounds like writing it in C or C++, then adding a separate binding library and that library could interface with any language and then you could do this and that... also don't. If this is the situation you're in, imagine you have your own allocator/deallocator, your own memory manager, possibly a thread manager if you have some mutable/immutable/atomic code, maybe some mutex/semaphores for multithreading, all those will clash with both the C# manager AND the Unity manager. While it's true that in Unity games most of the C# "magic" is handled by the framework, in reality, all Unity classes are handled by the engine, which is C++ and has its own rules. And while you MIGHT find workarounds for this or it MIGHT not be an issue, as the project grows and expands, you might have some surprises. Too many dependencies will add issues.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Sorry for the noob question but I've always had a hard time distinguishing situations when it's good to create a function or a class. For some of the smaller programs I write at work, I write a whole bunch of functions to carry out specific tasks. The programs all work as intended. However, when I have some of my more senior developers take a look to give me their critique, they rewrite a lot of my functions completely over as a class. These are my coworkers so I don't want to look completely incompetent (I just started this job as a junior developer) by asking them why they did that. What do you guys think?
That is too broad question and you really have to understand the concept of the Object Oriented Programming and when you should use it.
Note: Bellow you will find my personal opinions (some of them borrowed from great books' authors and experienced programmers), and for sure the things highlighted bellow, does not reflect the entire power of the Object Oriented thinking and design. These will be gained throughout experience and feedback.
0. A use case of a class
There are many applications, on where to use an internal class to your C# code.
Data Transfer Object (DTO)
One application (of really many) and is used many times in software, is when you are transmitting data from database to your application for processing.
What better than writing an internal class that will store your data, implement useful and re-usable methods that can be used later in your application logic (e.g isAdministrator) and so on.
1. Object-Oriented Design Patterns
I will recommend you reading a book about Object-Oriented Design Patterns.
Books like that, describe some problems scenarios that can be implemented with a class using a pattern. Once you have read about these patterns and possible scenarios on where can be used, you will be able to get the book, find the pattern and solve your problem.
A co-worker of mine, state something really useful. When you are facing a problem, you should ask yourself:
"Does this problem solved again using a design pattern?"
If the answer is yes, then you go back to your reference book to find your design pattern, that will solve your problem, without re-inventing the wheel.
This approach, will teach you how and when you should use a separate class; but will also help you to maintain a communication language between you and your co-workers, that is, if you are talking about your code to a co-worker, you will be able to state the design-pattern and you will be immediately understood (given that, your co-worker know about the specific design-pattern).
2. Don't be afraid creating more than one internal classes
Another note, don't afraid to create multiple internal classes. Implement as much as possible, don't try to implement one internal class and mix responsibilities. Your class should be for a specific purpose, and should not do more than one thing (i.e responsibilities, if you are writing a class that is about transmitting data from your database to your application logic, should not - ideally - doing something else, like adding data to your database).
Consider learn more about Polymorphism, Inheritance, Encapsulation and Abstraction.
These four fundamental principles of Object Oriented Programming can also help you to learn how to structure your code object-oriented.
3. General Notes
As a Junior-Developer and not only as a Junior but as a Developer in general, you should always willing to learn from the more experience guys, by asking for feedback. Is not a shame is the law of learning and improve your code.
Another powerful source of learning, is books, consider buy some for the area you are interested in. (e.g Object Oriented Programming, Design Patterns etc).
As others noted in comments, this is really too broad and slightly opinionated, but big picture, use a class when:
You maintain state over time, and apply functions to this state.
You have a set of functions that share a common goal or deal with a common usage, data type or otherwise "obvious shared idea". That's particularly relevant when these functions can be reused in other places.
But really, to get a deeper understanding, get a book :-)
BTW, in C#, you can't put any functionality outside of a class, so the question should really be "how to divide my monolith class to smaller classes"
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I want to build websites in a modular fashion, so I can get better code reuse and abstract away some implementation details. I'm looking for advice on how to code such a website with ASP.NET and Visual Studio, and modules for such a website, because at the moment my websites don't have this nice property.
At the moment I'm working on a web-app that's providing a pretty straight-forward internally facing contact manager for a company. We plan on using identical contact managers (pointing to different databases) for each of our independent customer-facing websites (each for one of the company's businesses). I'm using ASP.NET MVC in C# with EntityFramework. What I'd like, is to be able to simply drop this contact manager package/project/class-library into a Visual Studio solution for an ASP.NET MVC Website, and then just add whatever 'wiring' I need to get them working together. I've seen the use of "areas" within MVC apps, that basically function as mini MVC applications, but it's been messy and actually less maintainable because of configs and different areas wanting different versions of assemblies (this is not code I wrote, and I want to avoid writing code like this). I have an idea of what this would look like in terms of data-objects and box&line diagrams; unfortunately, I don't know what this looks like in terms of views, controllers, projects, or assemblies.
The thing is, as a relatively unseasoned programmer, I've never done this before, so need advice on how to proceed. I'm unfamiliar with the patterns/idioms I need to implement this. So while I have the theoretical knowledge of how to write nice modular software architectures, I don't know they end up looking like in-terms of their actual classes, namespaces, and Visual Studio Projects/Solutions.
My question is, how do I build a website that's more modular than your standard MVC? And, if you have experience doing this (or attempting to), could you please share it? Or even better, can you offer a concrete example of such an architecture? (note this will probably require a link to something not on stack overflow, since you can't copy and paste an entire code-base to stackoverflow).
Apologies for not having a specific question, but this is a bit more complicated than a simple query of "how to traverse a b-tree", "why isn't my code compiling", "does anyone have a regex to do the thing I want", "I wrote some terrible code and now it broke", and "I haven't read the documentation (assuming there is any) and now I'm getting an exception that I don't understand". There likely isn't a single answer, because programming is complicated, solving real-world problems takes thought, and writing good code can be hard. Also, I can't exactly post the code I'm working with because of this thing in my contract known as a confidentiality clause, and not that anyone would read through 100's of thousands of lines of code and tell me how to make it better. \end_rant
I think you are looking for the "Onion Architecture".
Here's a live implementation of the Onion Architecture over on GitHub that uses Web API, MVC etc. It uses the all familiar Northwind database. So you can browse through the code and solution after you learn about this architecture and make sense of it and incorporate the parts you need in your project / solution.
Also, here's a nice tutorial on how to develop using this approach.
Finally, a Channel 9 Video that was what I originally found a few years back when I was researching the same thing, and found it very useful.
ASP.NET MVC Solution Best Practices
This video also takes an existing monolithic project and turns it into an Onion Architecture implementation, along with reasoning on why we are doing what at every step.
First of all you have to direct yourself in implementing your systems based on an approach that can provide complex systems that will not make everyone furious in waiting.
This is commonly known as the Domain-Driven design.
Then comes SOLID. SOLID represents architectural choices that will make your system easy to maintain and extend.
See SOLID in action using C#
All these along with Patterns of Enterprise Application Architecture can keep you busy for all your career and yet it could not be enough.
trying to follow the above in your programming will give you eventually a "less-monolithic" system and modular.
In ASP.NET MVC terms the above could mean:
Keep the MVC paradigm. Do not feed your controllers more than they should eat. Keep them only for what they are. Traffic cops. Also do not put logic in your views in order to keep them abstracted.
Maintain your logic in a separate "space". By the word "space" i mean a separate project, solution, assembly....whatever you think fits to your application size that you are building.
Use MVC Areas for what they are supposed to be. They fit perfectly for the FrontEnd / Admin case. You want to have a frontend that looks and operates differently from the backend, but obeys some general system rules.
Use Web API to make your application open and expendable. This will bring Javascript into play which itself needs to be addressed regarding SOLID e.t.c..
Do not overdose your application with javascript frameworks just for the shake of it. Use what you really need.
Use IoC container like Ninject to manage your dependencies..Marry your interfaces and let IoC resolve your implementations
If you going deep in javascript , take your time to define your viewmodels correctly. They are the contracts between 2 different worlds so they must be clear.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Hello developers and designers,
I am very willing to learn WPF in which i use C# as the logic code.
Or i 'try' to anyway.
I have written a 2-page long code-behind in Forms-style though, so i know some syntaxes.
But that was a really cumbersome way of doing it.
The problem is that i am still lingering around the area of understanding at least the basic concept of object oriented programming. But 9 out of 10 times i am not getting the example-codes entirely because of that '1 little thing of which i don't even know what it's called'.
How do you even know if there is a command for the function you want to express and more importantly.... how it's called and where it located in what namespace?
Even the best video-examples aren't doing it for me, because when any code is typed, they never explain how the code exactly works. And most of the times it just doesn't even add up to what i know of logic code (of course i'm wrong).
In the early days i learned the Commodore64's Basic no problem.
Learning and writing Actionscript (Flash), within 2 months creating a 2D-shoot'em up
Learning and writing CMD, within 3 months writing 5000+ lines of code for all sorts of functions.
Why in Merlin's beard is WPF so hard?
Watching the "simplest" tutorial-video's are becoming more and more de-motivational.
Anyone recognizes this?
Thanks for reading,
Danny
Regarding WPF the articles I've found to be most useful are the overviews on MSDN, they might take quite some time to work through but they are concise and in-depth, see this page for a master-overview.
Why WPF is hard is a good question, one primary cause might be that it is simply huge, at least i perceive it that way. Aside from having all the code you also now have XAML markup which is a world of its own.
Someone from Microsoft who did a presentation on F# in 2008 said that if you know three of the keywords, let, fun & |>, you know the whole language, which is not even that much of an overstatement. WPF on the other hand is not a language, it is a sub-framework. If F# can be likened to 3 nanotechnology building blocks then WPF is a 50 meter workbench stacked with tools (the controls) and a dozen heavy duty machines (WPF mechanisms like dependency properties, data binding, commanding, data templating, etc.), and all of those come with a manual. So if you are facing a problem you pretty much need to know what all the tools and machines do so you know which to use, and then of course you also need to know how to use them, apart from their basic functionality each may even have its own kinks and peculiarities which are important to keep in mind.
So learning WPF requires a lot of raw knowledge of the framework but also experience so you know what is the best approach in a given situation and to get a feeling for what can be done and what cannot.
MVVM: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
Learn it then use it.
I figured I'd add my $.02 since I've recently started using WPF. First off, you'll need to read that MVVM article mentioned by Fëanor, and DEAR GOD, download the sample code and learn what every line in that program does! Reading the article is great, but seeing the code, running it, changing it, etc, is INVALUABLE. I also echo the comments about the MSDN overviews, and the one about creating a side project rather than learning WPF via an existing project.
Other than that, don't expect to get WPF in a day, or even in a week. I've been using it for about a month now, and I've still got a ways to go. I had my "AHA!" moment about a week ago where everything started to click and it became apparent to me what I DIDN'T know which is important. A good strategy would be for you to pick a single concept such as Data Binding, or Data Templates, or Styles, and explore each in depth. It's a lot to chew on, so just remember that Rome wasn't built in a day. And if you're not already comfortable with data binding, I'd pick that up early on since it's pretty crucial.
Lastly, once you learn WPF, it's going to be REALLY hard to go back to using Windows Forms :)
Have Fun!
Q
I don't think that WPF is actually that hard. I think it's just that WPF definitely requires a slightly different way of thinking. You can tell that it was built with certain principles in mind (like MVVM, as another poster mentioned), and it's very different from most other frameworks. If you try to do it like you did Windows Forms or MFC or ASP.NET or whatever... you'll struggle. You need to be willing to change your mind on how things work.
Frankly, I think the only way to learn it is with experimentation. Come up with some side project to work on using WPF and try your hand at it. Learn a bit and refactor it. Get a good book, read the WPF disciples list, read anything that Sacha Barber writes, read the WPF section here on SO.
When you have your first "ah ha!" moment where you decide to write an Attached Property to solve some obscure problem you're having, you'll know you've finally understood it :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am not the only programmer, but I'm the only .NET developer, everyone else works with Perl, Ext JS, and related technologies. I'm primarily self taught, using Codeproject heavily to learn new techniques.
Without any mentors at my company specifically knowledgeable in .NET, I'm unsure whether classes, or online tutorials, books, or perhaps some other avenue might be most effective at helping me to become a better developer.
My goal, optimistically, is to become a developer capable of managing the next .NET developer we hire, or at least to integrate well with him/her.
I'm currently taking on the task of documenting my programs in such a way as to receive review from the more experienced developers at my company regardless of them not knowing .NET, and I expect this will be rather general, but hopefully still beneficial.
Does anyone have suggestions or advice for how to most effectively learn good practices without direct oversight?
Without mentors around, there are several things you can do to improve your skills:
Take classes...especially if your employer will pay for them.
Read books. They're the next best thing to a class.
Read developer blogs. They may not teach you best practices, but they'll keep you abreast of what's new in the development world. That'll help you keep from falling behind.
Courtesy of the Community Listen to Podcasts (Hanselminutes, Stackoverflow, etc.) and watch Screencasts (Dimecasts has tons of good content).
Participate in the community. We may seem harsh at times, but you'll hear the most about best practices, coding techniques, design patterns, etc. and different ways to apply everything.
I have always worked like that. My ways to improve are:
Reading high-quality blogs
Applying what these high-quality blogs recommend (whenever it fits your project and when time allows, of course)
Reading high-quality open source project's source code
Writing as much code as you can, always keeping in mind what you've learned and always trying to raise the quality bar. Practice does not make perfect. Only perfect practice makes perfect.
Keep an eye on stuff that's unrelated to your own line of work. For example, if your main job is coding ASP.NET in C#, read stuff about functional programming, F#, Haskell, other web frameworks like django, Ruby on Rails, etc. I'm not saying that you learn them, just see how things can be done differently. It will broaden your perspective.
When you gain some self-confidence: contribute to open source projects, write a blog.
About books: IMHO the books that are highly-technical (i.e. "Buzzword 2.0 in Action!") aren't worth your time. Everything happens so fast that they'll probably become obsolete 6 months after their release. The only books worth buying are those that deal with the underlying CS or architecture issues.
About classes: it's very hard to find high-quality non-university classes that aren't a waste of time/money. Most of the time you can learn faster by yourself. (UPDATE: fast-forward to 2013, MOOCs are an amazing, high-quality, free learning resource)
Also be wary of codeproject, there are lots of articles there with errors and/or general bad advice.
I am in the same situation you are in. I learn mostly from
previous projects/mistakes, especially when you take over an old project from someone else (50%)
google (25%)
forum/stackoverflow (25%)
Change employers. I'm not trying to be a jerk, seriously. The most growth your going to have as a developer is by working every day with someone significantly better than you.
Join some OSS project which works with .NET to get feedback on your code from experienced .NET developers. In addition looking at other people's code is a great way to learn new things - just as you have been doing. I also agree with Justin also that reading blogs like Eric Lippert's is very rewarding
Take advantage of the chance to learn the languages and technologies being used by by your colleagues.
They'll introduce you not just to syntax, but more importantly to techniques, idioms, and paradigms that you won't find in .Net, but that will challenge you to think about how you could apply or build those thing in .Net, or why .Net doesn't have or shouldn't use those things.
Why is Perl weakly typed (or is it)? What's Perl better at than .Net? What is .Net great at the Perl is just terrible at? Why do these differences exist? How might you implement a Perl interpreter in .Net? Why might you want to?
Why's everything in a JavaScript a hash? How does .Net class inheritance compare to JavaScript prototypes? Are JavaScript's first-class functions a great tool or a source of obscurantist abuse, compared to .Net's strongly and statically typed classes?
What are the fundamental data structures in each language? For each language, why are those types fundamental to that language? What were the different design decisions (or lack of decisions) that motivated and informed each language's design and implementation? Can you discern any common "ancestral" languages among the languages used at your workplace? Why don't we have "One Language To Rule Them All"? Should we?
Finally, excellence at any one language is really great to have, but unless you're sitting on that language's Standard Committee or writing compilers/interpreters for that language, a broader knowledge of the underlying algorithms and data structures and patterns that are common across languages is probably more important to your development as a programmer -- and certainly to managing programmers, if that's your goal.
Look for local .NET user groups. In most cities, you are likely to find at least one. User groups are a great place to develop contacts, ask questions about the technology and basically get answers to problems you may be experiencing. If there are no user groups in your area, try looking online.
If you are free to choose how you develop, and you get new projects fairly often, pick a new technology you're not familiar with to use on each project. Of course, do your research first and make sure it makes sense for the project.
At my last company, I was pretty free to use whatever I wanted as long as it made sense and worked. I always tried to use something new on each project. The last project I worked on, I used NHibernate. No one told me to learn NHibernate, but I took it upon myself to use it to expand my knowledge. Of course, I made sure NHibernate was acceptable first.
The best way to learn something is to use it. Classes and books are good, but nothing will make it stick more than using it in a real project.
My goal, optimistically, is to become
a developer capable of managing the
next .NET developer we hire ...
In that case, you should be looking to expand or improve your people/project management skills as well as developing your technical programming and design skills in your chosen technology.
I also subscribe to the view that it is not a good idea to focus too much on a particular technology; e.g. .NET. Too much specialization tends to limit your career prospects.
A year ago I was pretty much in the same boat and it's interesting when I look back at the things I wasn't so good at. Awareness of the technology you are using is an important one, many people have suggested reading books/blogs etc which are good.
One thing that may help you, is to look at the MCTS material, starting with a foundation exam (I'm working toward 70-536 .NET 2.0 Framework exam) to make sure you have a good base. One of the advantages of this is one that it is credited by Microsoft so you can add it to your CV for the future and it gives you a more structured approach than just reading books.
Secondly read up on design practises, or even design principles (such as Gang Of Four). Do your best to not cut corners, and develop your code in the best re-usable way. This keeps you thinking about design and maintainability which is extremely important.
Finally I'd probably suggest trying to ensure you're not doing the same thing over and over. Don't just work with databases, or UI's etc... Try to get a mixture of things to try new techniques and learn new stuff.