I’ve seen something happen many times during my longish tenure as a software developer being amidst to some others who are new to it. They seem to have a complete lack of wanting to understand something before tearing into it.
I have experienced this in the past and I see it at times at work. Instead of owning up to some facts about a lack of understanding – they want to pump out some code and show everyone they are wizards. They got it.
Only wanting to break the finish line tape…
Then they ask for some working source code without worrying about how it actually works. They try to plug it into what they already cobbled together and have a hard time working with it – getting it to work. They don’t know about scope. They don’t know about classes, extensions, or how to best wire up various aspects of their UI.
They ask for completed code – but don’t typically search StackOverflow or even Google things. If they do, they don’t worry about what makes it work. In the event they do get something working, if they are asked to make tweaks or changes, they are screwed. Why? They don’t know how it works – or know enough to make the change easily.
They fight with code and concepts. They want to get to the finish line in whatever they are doing – by skipping the race. In the end, they may eventually get to what they are after. But they aren’t putting the work in, the investigation, the basics of design and development, and in the end, they are only slowing down their development.
Being a developer shouldn’t be about ego. If you don’t know something, don’t be embarrassed to ask teammates. Don’t downplay your struggles.
If you don’t understand something, take the time to learn about it. Create test projects or Swift Playgrounds and bang some code. Read articles and tutorials about making things. Try them for yourself. Once you have a solid foundation, you’ll be able to more easily approach challenges and deliver projects that you understand.
Use comments in your code – and place questions, TODO or FIXME, and MARKs there. This is especially handy if you’re working on something in source control with other team members. They have a chance to see your stuff and be able to offer up help. Don’t rely on this though.
//I don't understand this, can someone elaborate? //TODO: Why is this not working? Need some help. //FIXME: This isn't working, how come? //MARK: — Section Marker
When you do this, you’ll see those called out in the source file you’re currently working in (except for comments – but still useful).
Development shouldn’t be about wowing your co-workers. It’s about delivering great experiences in a timely manner, with the ability to iterate quickly along the way. Communicate your ideas and approaches. If you’re calling on others to help you bang things out – that’s good. But not in lieu of understanding what they are doing and why they are doing it.
If you are relying on others to do some pretty conceptually basic things over and over, they will become less likely to assist you in the future.
There is no escaping time and effort. They are no substitutes for trying things, learning things and failing at them. If you learn slowly, you’ll forget slowly. Spend time outside of projects to learn core concepts. Code, code, and code some more. Look at applications you like and think about how they might be composed (backend and frontend) – and then try to build that part yourself as a prototype.
Start simple… tables, collection views, loading assets, playing sounds, using gestural input, etc. Get those things nailed down. Then subclass some UI to do something special. Learn about delegation, Classes, extensions, etc. Grow slowly. Build upon past prototypes. You’ll have something to lean on moving forward. Every day will get better and better because of your efforts and you taking the time to learn how to develop for the platform.
You’ll be much happier in the end. You’ll know more. You’ll be able to produce more. You’ll be able to iterate quicker. You’ll be a better teammate.