Why would you "build a socket".. what does that mean? Sockets are a very basic, very old construct, which for the vast majority of applications should be completely abstracted away. Its 2012. Why would you learn C if you wanted to build interesting things? I would learn C if I wanted to be the next Linus, but not for a whole lot of other reasons.
You need to be willing to put in the years of practice and able to find stuff that is easy to do but mildly interesting to experiment with.
If you want to make cool stuff, learn how to take advantage of other people's code. For example, I am almost afraid to mention it on here, but there is this thing called .NET where they have controls you can drag onto a form that does lots of stuff without writing a lot of code. If you learn how to use those types of things, you will be a better engineer. The best engineers write less code and take advantage of all kinds of tools and widgets (that is not a popular idea, but its true. ASCII source code is primitive). There are also all kinds of 3d game engines and editors that give you a head start as far as making interesting stuff, for example Unity 3D or Unreal.
Maybe you could just install WordPress and start learning about all of the plugins. Figure out how to configure WordPress to be like a site you think is worth copying. Find an example plugin, copy it and then change it a little to do something slightly more interesting to you. If you are able to use WordPress to implement a site or application that takes someone else twice as long to 'code by hand' or use some other CMS and it works just as well, then even though you didn't write as much code, you did a better job of engineering it. Generally its better software engineering to reuse code that other people already wrote and tested. It may not make you feel as 'elite', but its better software engineering (again, not everyone understands that, but its true).
Objective-C, I think besides being overly complicated and a bad starter language, I believe that entire thing is a big circlejerk and waste of everyone's time. But if you are into circlejerks, there is lots of money to be made in that area. So the way to do that is to find the best tutorial with complete code, follow it, copy all of the code, and start tweaking the app.
I recommend CoffeeScript for a language that makes sense. Same general approach as above applies. http://pcsedit.appspot.com/#edit/mbarkhau/example.coffee
Last thing, its normal to have lots of little problems to solve, things that are more or less trivial, because every single thing and every single character in your program needs to be perfect. So no matter how many years you program or what level 'engineer' you are, you have to get used to being stuck on things.
The trick to being unstuck, depending on what you are stuck with, is 1) knowing how to use Google and copy or use what other people have done that already works and 2) in the case of debugging, having practice debugging. Usually you want the best debugging tools available so you can see into the operation of your program step by step, but you really only have to have a way to output messages.
Software engineering is about feedback loops. You can even look at object oriented design as a feedback loop. Look at a chunk of code, if its hard to understand, break it into a smaller chunk. If you start repeating nouns, make an object. That sort of thing takes years of copying what other people are doing and studying and practicing before you are good at it. But anyway for feedback, its between you and the code. If you come back the next day and see large methods or code that is hard to understand, then you just gave yourself feedback about how you can refactor to make it simpler.
Or take test driven development and QA. Again, its about feedback loops. When you have a manual QA process or no QA process at all, you only find out that something is wrong or some code that you just changed affected some other code when (if) you are lucky enough to click on the right thing. When you have a QA process, or if most methods in your codebase are tested automatically whenever something changes, you get a tighter feedback loop, i.e. you find out right away when something is wrong.
Or take part of the basic idea of 'agile' or 'lean'. Again, about feedback loops, this time between you and the group you are producing software for. The shorter the time or distance between your coding and users trying to use the system, the faster you can fix it to be just right.
Software engineering is not about writing the most code or the most advanced code or about writing code at all really if you can avoid it. Take advantage of open source software, components, GUI tools etc. and get useful software into the hands of users, and you will stay motivated enough to expand your elite ASCII coding skills while at the same time doing software engineering.