You need to go through at least three Design-Ship-Support cycles of the same product to really appreciate what good coding practices are.
If you're like one-of-many in a project and never really have responsibility for anything I would strongly recommend some external work where you are in total command of everything. I was stuck in a position without that for too long.
------------
By the way: you say you just know C. But how many developers out there feel bad about their skills because they don't have C skills? C is the beginning of everything, everything is built on top of it.
Even when it was technically outside the requirements of my job, I started stepping up and actually fixing my own shit. And not just bugs or issues, but really feeling the pain of having to deploy it, talk on the phone with the customer and feel the lack of help/debugging stuff built-in to the product, train new users on how to use it, feel the panic as you realize that you cocked up the last deploy and it's going to be offline for like an hour while you scramble to roll back the changes which you thought you figured out months ago but everything changed since then and you are sitting there with nothing.
Slowly but surely I started adding things to my "never do again" and my "needs to be done before launch" lists.
If you have to take total control of at least project, you'll likely be doing it for all projects.
If the previous project was created by multiple people, but you are now the sole maintainer, it will take more time to work on than the other projects. These are the ones for which you should know like the back of your hand when juggling 10 other low-impact, one-man-army projects.
Lack of QA and Ops means you are limited by your own working set of skills, which is most likely going to be shallow in those areas. It's also very hard to learn dealing with customers on the job in this role -- it's best to have learned it somewhere else. You can write unit and automated tests, but that increases your development time 3 fold (not to mention you already need good unit testing and automated testing skills).
You will feel like you are constantly drowning. The highs are not really that high and the lows are very low. There is no opportunity to master anything other than making the customer happy for a month or so, which is really only so you can meet other customer needs.
You may not have an additional person just to bounce technical ideas off of. This is so much bigger than you can realize if you've gotten used to this kind of one-man-army position, chiefly because you often have little time to actually think about what would make the products better.
None of this feels like growing, only surviving, especially if the next position is going to be a place that has experts in all of the extra areas.
It's not ideal, and I'm actually happy to be moving out of that (with what used to be my "one man army" project actually getting a team and managing it).
But holy hell did it teach me a lot!
* Have a testing framework in place (you don't need 100% of tests written during dev, but make sure your shit is testable and written with tests in mind)
* have a deploy plan that is one step
* have a rollback plan that is one step
* have backups running way before launch
* have one-step restores from backup running before launch
* make sure your restores make their own backup before running (yeah... that day sucked)
* write enough documentation that someone not involved in your project can setup a dev environment and make simple changes/deploys/rollbacks
* document your production system setup and make sure you can reproduce a production system from your documentation alone (this WILL bite you in the worst possible time if you need it!)
* make sure you have a plan for database migrations and it works 100% of the time (and in both directions! Have a "deploy" migration as well as a "rollback" migration for every single change!)
* Have someone that is not a developer use the app without any documentation (this is huge)
* Have a lot of logging and a way of easily viewing them (you can always turn logging down fairly easily, but adding it after the fact is a lot more work)
* build a lot of "support help" tools in from the start (things like the ability to see errors that happened from a specific user, or at a specific time, or in enterprise applications the ability to grab screenshots from the device that is being helped, or built-in remote desktop if applicable)
* Get a bug reporting system in place so users can easily send you problems and issues with as much information as they are comfortable with
* make sure you can deploy hotfixes easily and at any time even if the live version of your app is months behind master
* plan to have more developers at some point. Even if you don't now, even if you can't fathom having more than a few people, just keep it in the back of your head that there's a chance that 10+ people could be working on this code, so maybe that cute one-liner shouldn't be used here...
* stick to a style guide
* put a version number somewhere visible in your app (even if it's REALLY small) so when people send you screenshots you can instantly tell if they are behind or up-to-date or if they got yesterday's hotfix, etc...
And a lot more i'm probably forgetting...
I will give one warning that a lot of what I really learned is when to prioritise one of these things and when it's okay to let it slip.
Like should I push the launch date back 2 weeks to implement bug reporting? Is it okay to launch even though I don't have 100% test coverage? When should I prioritise writing tests for the remainder of the code? How much time is too much time to test a particularly difficult to test portion of code?
I don't really have answers or rules for those, but after living through each of them, I have a much better feel for what to do. And as always, shipping is better than not shipping. Code that you never release because you are always trying to make it perfect doesn't help anyone. At some point, good enough just needs to be good enough.
Quite honestly, I wish more tech interviews would focus on this kind of stuff rather than language trivia and "stump the chump" algorithm questions. It's 100X more important to the success of a project than how you would implement quick sort.
But at the same time, most of those things on that list many people would consider "obvious", but when the deadline starts getting close they start slipping (because shipping on time is more important than some stupid logging shit!).
Then before you know it you are a month after launch and you are drowning trying to figure out what the damn emails mean when they just say "The app won't work" and your boss is still pissed from the deploy you did a week ago that ended up taking over an hour because you never tested the restore system, and every few days you get a report of the whole thing crashing but you have no idea where, why, on what platform, or anything about it.
That's the kind of "lesson" that I ended up learning. Pushing the ship date back a week or 2 isn't really that big of a deal in 99% of cases. And having good ops in place, a healthy amount of testing and support code, and some nice documentation doesn't take that long if it's done at the start, and can save you a LOT of time and grief in the not-so-long run.
You say it like a joke but its actually very good advice. If you have a working app break over the weekend, it could be a disaster.
There's a similar axiom an old surgeon told me: if you can help it, never plan a surgery that will end when the working day closes.
A user gets it, it's "too fast", the designer wants to put an animation in there to slow it down and help give some context. Of course the animation means that once you "clear" the dialog it flashes to blank before "animating away" (because it's a beautiful stateless functional component!).
So now the code is this hideous hacky bloated ugly solution, but it works...
But it was just more of a story about how sometimes ugly hacky code is better. Because at the end of the day, you are writing this for the user, not for yourself.
I think another good one is when you are fixing a broken production system, and end up having to revert to running a debugger on the code (involving various hacks to get connected to the production DB/etc), only to realize the entire problem was a simple configuration setting -- which would have been totally obvious and fixed in seconds if there was a bit more logging and/or a better error message.
That's the stuff that comes out in the Support cycle that I think people really only internalize if they learn the hard way.
Alternatively there's nothing like having a junior colleague investigating a defect in code you once wrote ask you what it does and then have to publicly declare that that it was crappy garbage that you can no longer decipher.
My future self is always happy that this is the new standard. High quality, documented tech debt.
This is one of the reasons why my current shop has added a new rule. When dev gives my ops team a new release, one of the devs comes to our office and stays here during the initial deployment and test. It's a good feeling to see a dev equally confused about weird crap the application does because it doesn't log and it doesn't work and it's just weird. And for bugs in on-premise systems outside our network, the support devs have even more fun.
Overall, this is a pretty funny development. Both teams grew a silly amount relatively speaking, and due to stress and other issues we had a couple of tensions between teams. But by now both teams are learning.
Ops is annoyed because of some weird config, and dev hates this weird config because it's a huge pain in the code. Oh, teams talked, config was ripped out and simplified.
Dev is desperate about a hard bug regarding request headers, because this might need a hotfix and logging and changes. The admin just shrugged and changed the apache access log with said header, and the problem was resolved 15 minutes later.
I think this is one of the bigger lessons for me. Never assume something to be hard or easy for another team. My huge issue might be a 2 line change while removing a huge pain. Your issue might be something my config management already does.
What was happening is they just accepted the software the way it is, and because they were capable of writing this complex script, they didn't see the need to ask for help or changes.
I've spent some time recently learning more about the specifics of their deployment and have some changes to make as a result (though since deployment is working, it'll be a slow change since it's more like technical debt and not an immediate problem).
However, I think I'm actually going to suggest we do what you're doing, and actually make a developer go sit with ops whenever they deploy a new release. That's a great idea, thanks.
And then there's that one in-house application. It's easy to just lump it into the pile of crap we need to deploy and maintain and handle it in the same way we handle the other services.
And at least at this shop, this was reinforced further for some time. We in ops had two choices: Either, we block a release for hard reasons, no matter how close we'd have to look for them, then we'd get some bandaid quickly. Or we could attempt to explain a highly technical issue or a really weird configuration glitch to some entirely non-technical product management, who put it on the latter half of the "never happens" backlog inside the round ticket storage, which is groomed daily by the room services.
At this point, just scripting around bullshit costs me like 2 hours to do, while all that other nonsense easily costs days and days.
But yeah, all of this is being mediated because devs now see the amount of nonsense we have to do, and they can relate this nonsense with their own testing problems, their own dev setup problems and overall, both teams start to support each other against sales and PM.
I would argue that basic comp-sci principles and common language meta-syntax (mainly those derived from the fortran/pascal/c branch of things) is where everything (skills) should be built from.
I'm not expressing this clearly; I know that. What I am trying to get across is that if you understand the fundamental principles (not necessarily the deep-dark parts of comp-sci where wizards roam) - you can apply those to almost any language (save for a handful or so - there are some languages out there that look very esoteric; LISP for one, but there are others on the functional language branch and other areas where the mindset for developing in them is quite different.
That said, most of these "other" languages tend to be academic in usage (not that they aren't interesting in their own right!); that is, you won't generally find them much in the "real world" business area - not usually. However, sometimes you'll run across an employer or two willing to pay big bucks for that one expert developer to help them with their project in some language that isn't widely used. They are paying the money because the supply-demand curve is very skewed, but I would hesitate at taking such a position - while the money may be good, you could pigeon-hole yourself if you aren't careful.
I started my "real" development career (I'd played around a little before then) while employed as an Admin Assistant at a company that used an Excel spreadsheet to track work coming in and out. Every task had to be repeated 4 or 5 times, as the company needed different views for different managers. Oh, and of course, only one person could use the spreadsheet at a time.
After a few months of typing this in over and over I got sick of it, and fired up Access. In the spare time I had here and there I put together a database everyone could use at once, input once, then open up appropriate views for different managers. I did a lot of this with the Access visual query creator tool. My manager was blown away when he saw it and gave me permission to keep building the feature set out - I'll be forever thankful for that, because many in the company resisted.
I added and added to that database, learning VBA for the more advanced stuff, until Access became too limiting (I honestly can't remember why now). We didn't have admin access on our machines so I couldn't install Visual Studio Express, but I could install SharpDevelop. So I did, and created an alternative front-end in VB.NET using the same Access database, eventually graduating to SQL Server (again, I forget why, but I think regular backups were one particular reason. I remember a phone call with a very confused rep from our outsourced IT provider wondering why an Admin Assistant wanted a SQL Server database).
Nowadays I work in Node, create iOS apps, all sorts - I've left that original environment far behind. But I wouldn't be anywhere near where I am today without those sandbox environments that let me learn and grow very quickly. People are quick to dismiss Access, VBA and all that, but they shouldn't be.
The same applies to game mods (minecraft now, warcraft3 years ago) where people love playing a game, get introduced to mods, and then make one for themselves. Each modding community has a field of experts with the same passion for the game as noobs. The experts produce documentation and sample code for the noobs.
The noobs have a "sandbox" to play in by modifying the game. First they follow tutorials or copy/paste code into patches. But eventually something remarkable happens when they start to modify that logic to accomplish their own goals. It's at that moment a programmer is born.
How many people started programming by modding games in a hex editor?
How about installing phpBB mods on a forum for your favorite game? That's how I got started.
How about editing jailbreak themes or tweaks?
Or running some metasploit module against your printer?
Or setting up your arduino to run Xbmc?
The common thread is that these are all sandbox environments; games, pluggable open source software, jailbroken phones, emulators, arduinos. Every sandbox also has a community of experts backing it and providing an invaluable service to noobs. These communities serve as an entry point for self-selecting, motivated autodidacts to gain exposure to programming. These are likely the people who become the most prolific, or at least passionate, programmers later in their career.
This is almost exactly my first programming experience.
I discovered GORILLAS.BAS [0] on our family computer and, after playing it for awhile, discovered that I could change things about the game by modifying the strange text on the screen. First I was changing colors. Then simple drawing changes. Eventually, I had a version that replaced the buildings with mountains and the gorillas with artillery guns. Gave it out on floppies to a few friends with simple instructions on how to play it.
It was at that moment that I realized I had created something pretty awesome. Never forgotten how that felt.
In my job after a period of learning and implementing the current processes, I wanted to make it better and my job easier. I did some Powershell scripting to begin with. Then I needed more so I started building C# WPF applications to manage and automate these processes. When I began developing it started out as merely a front end to some CSVs. Since then more and more people started using it and giving feedback and suggestions. It became a passion for me. I hit so many walls along the way and overcame them with internet resources and tutorials. Sometimes I would work weekends on this project. After many feature versions, bug fixes, and refactoring to address maintainability, unit testing and administrative/logging, it grew in complexity and users.
I had a similar experience. I was an junior accountant at my first job - I was tasked with combining a bunch of timesheets for several manufacturing facilities into one large timesheet to calculate payroll weekly.
I quickly grew bored of this and learned a bit of VBA to do automate the process, started learning RoR, Django, and moved on to technical jobs at other companies.
Funny thing about those first scripts I wrote - although they were relatively bugfree, they didn't account for having been run more than once per week. So one week when I was out of the office (and had run payroll remotely) a colleague ran the scripts and everyone was paid double. I left the company shortly after.
Didn't Access have a 20-or-so-simultaneous connections limitation? I guess it depends on how old the version. Yes, I tried using Access on a website once (Lowers head in shame).
When you first become a developer its much easier to learn new things with just a little bit of direction. You may not always learn the best way to do things, but you're learning. Eventually I found that I hit a plateau. I was technically knowledgable and could learn new technologies fast, but the quality of my code wasn't changing significantly. I've found that this happened because the feedback loops for this type of work is much larger. It can take you years to see why your architecture is unmaintainable, because it technically works and is much more subtle.
The new company has hundreds of developers, all really smart. We do peer reviews for all new work, which helps you learn from the experience of others. We tend to work in pairs, some people do actual pair programming, some people just bounce ideas and questions off of their pair, and all code is peer reviewed. It's very informal and isn't really written down anywhere, more a part of the company culture. My pair works on other projects than myself, we each have a number of projects we lead, but we're both very familiar with each others projects and could take over in their absence. Helps us learn from the experience of each other.
The other big thing that changed with the new company is the writing of tests. Prior to this, I hardly ever wrote tests. Now, I write tests for any new code. Sometimes this involves TDD, and sometimes it's just test-heavy development. Again, we aren't dogmatic about this, and there's often code that is untested. This is usually parts that are unreasonable to test, or wouldn't benefit much from tests.
Moving to a larger company with many teams of developers forced me to expand not only my technical skills, but my soft skills as well. Being able to work with many different team members, as well as across teams and with different business units forced me to improve skills that I didn't have the opportunity/need to improve on at my old job.
That is very inspiring. Thank you!
Also a very important thing that I've learned over the years is that the difference that a Developer has and a Junior Developer is the confidence that he/she can succeed the task handed to them.
I personally as a developer, think that I can achieve anything you give me task wise, no matter the technology involved, I'll just learn it and do it. The time etc of course will vary and if you give me something hard that is out of my current profession it might take a lifetime to complete but my confidence that I will get it done is what makes me a developer (I believe).
Once you find the confidence to call yourself a developer then you'll be a developer.
Note: That leagues of developers vary a lot. I'd consider myself a very median developer, and I've seen others that are doing crazy things, that doesn't put me down. I am as valuable as they are, one person might be lacking a bit on maths but might have a better artistic side and the opposite. Generally over the years you will see people doing things that you think it would take you a lifetime to do but its just who they are. Don't lose confidence, your skills will be as important as the other people skills. Personally I combine an artistic side and as a median dev I can create nice mobile apps and websites and work both on the backend and frontend of things and thats helping small companies that employ me to get a kickstart. If I was to go to google, I'd prolly fail all the interviews and people there would be a lot better technically, but again they might not be able to bring the same skillset that I bring to those small companies. So by saying that I believe everyone is different and anyone can find a fitting place as a developer.
If a project is 4 weeks long I'd spend 3 weeks basically pissing around and then 1 week blitzing it. I mainly got away with it because I was smart and fast, but got in trouble sometimes when they'd be a surprise "show us where you are".
Somewhat ironically, the best thing to cure this is to make a bunch of stuff. Make a prototype as fast you can. Make the prototype outside the existing system if it's complex. This especially holds true for things in web programming where a lot of things can mesh together as well as you needing to make an input form in HTML that might need to be complex and then suddenly you're dealing with how you'd make X complex control in javascript and dynamically load Y from the database. Ignore that complexity for now.
An example is if you need to make an integration with an API, muck around with the API in an isolated console app first. Hardcode the input params, don't even bother accepting arguments. Manually change them and re-run to test different inputs. Roughly map out the API, then cut and paste the bits you want to keep, rewrite the bits you don't. If you're a junior and don't know how to make stand-alone apps, learn, it's easy (you'd be surprised how often I've come across this, junior web devs only knowing how to write something in ASP.Net but not knowing how to make a simple console app).
Another trick when I'm really prevaricating or avoiding some particularly nasty or boring code is to write the code in comments. Delete each comment as you've replaced it with real code. It's usually enough to get me started. I even often write just a few comments and then because the design's finally clicked in my brain start writing the actual code in impatience to get it done.
//set the start date to start of day
//set the end date to the end of that day
//foreach thing
// parse the param
// validate param
//etc.
Naming can also be hard, if that's getting you stuck, call the method "DoThing" and write it, then you'll usually know what to call it by describing what it does.Or focus on getting one bit done. If it's a report, I always write the SQL standalone first, use a bunch of hard-coded params at the top of the statement that I can comment out when I copy it into the method and start parameterizing the query. Then I write all the scaffolding around it. If it's something that's got complex back and front-end code, I get one bit of it roughly working before the other (usually the front end with a dummy object), I don't attempt both at the same time.
TLDR; Stuck? Break it down in to chunks and tackle the smallest thing you can to get you started.
Now, many years later, I can reaffirm this. Teaching others something requires you to understand whatever you are teaching them, and even though you think you already understand something, when you teach it you force yourself to communicate it in an understandable way to others. In addition, you sometimes will have to do some more research to learn more about what it is that you will teach.
I started blogging about a decade ago, mostly about things that I found were interesting and then decided to actually dive deeper into the subject, and then write up a blogpost to explain the subject in understandable pieces.
Later in life, at university, I did some teaching of students whom struggled with several programming courses. Once again, I learned a lot from this. Sometimes they had questions that I never would have considered and then had to look up, to explain it to them in the next lesson.
And now in the industry, where I work, we give "devtalks", we can talk about anything technical we want and teach it to the others (whomever attends, but usually attendence is about 50-60 people). I like "going deep" in technical things, so I force myself to "go deep" and learn more about what I will talk about and then once again, present it in an understandable way.
---------
This is maybe not the thing that let me grow _most_, but I would certainly say it is a valuable addition on the road to become a better developer. And besides, the other commenters already hinted that there is no "single thing" that let's you grow most ;-)
Those who know, do. Those who understand, teach.
A lot of the comments I see align with how myself and my apprentices have grown.
It starts with fear. Being scared of screwing up. Then comes the first epitome. I can do this.
Then the new scare, shit I don't know this, I'll fake it, overcompensate and assume I'll pick it up, or research it quickly enough to look like I know what I'm talking about.
After that(eventually) it's acceptance that I have more to learn.
For me, as a chef, it was a few, months ago.
(Well it was the 3rd time honestly). I don't know everything.
Now to put this in perspective, I have been head chef of 5 star restaurants in Australia. Some of the best of the best.
My realisation point was finding out someone who could hands down push out pans dishes both faster and better than I could.
I have been doing this since I was 16, and my parents were chef's . I assumed I knew everything.
Since then, I have spent a lot of time watching them do what they do, and how they do it.
Now I'm an amateur programmer, I can do it PHP, MySQL, c# and vb.net, and I spend a lot of time googling, but I think the two industries cross in base learning more than price expect.
The point when we are challenged, not by difficult jobs, but by people who know more about that subject, is when we grow. If we take it objectively.
If we assume our training is bad, or were not good, we fail.
That's my 2 yen
When you come home after working, do you prepare your own food?
So about 56 per week. I try to take every second Sunday off.
During my split I'll prepare my wife's dinner, (cooking it if I can ahead of time), on my days off I enjoy cooking for friends and small parties.
On a side note, I love how easy it is to support your passion now. Between Instagram, blogs, YouTube and ebooks, I'm making combinations I would never have dreamed of when I was an apprentice.
The times I've learned the most are when somehow I've ended up in a job where I know nothing. I might not know the language (this is how I ended up learning things like C# and python, java, etc) but just keep searching and reasoning your way through it. If you're new to something, you'll be learning lots of things left and right because it's all new to you.
Same for jobs (different companies do things differently), people, projects, etc. Getting around and trying more is really all you can do to get that real world experience. Just don't be afraid when people say no. Or find a place where your deep knowledge can help them, and then you can also pick up some of the other things they do.
It also sounds like you don't interact with a lot of other teams or codebases that may exist (or may not) at your job. Maybe offer to try some of their easy tickets to just get acquainted with it? (your boss might even love that you care)
The code was not great but it worked and still works with no issues 3 years later. I get a nice check from it every month but try to not look at the code base because it is horrifying.
I learned a ton though during that time. Fear is a wonderful motivator.
I'm convinced this is part of what drives home so many "oops" lessons for me and helps me figure out what I can do to mitigate them in the future.
For example, I learned the value of caching when we launched a client's site on a nationally televised show. We didn't have caching and when tens of thousands people hit it after the show's host mentioned it, it went down. Just as we got it back up, the show aired in central time. Boom. And
That was a bad day but I will always remember the value of not just writing code and delivering a website, but trying to understand how it will be used and in what capacity. And caching. Always caching.
For me, deadlines are a motivator. I'm a horrible procrastinator but I do my best work right before a deadline
:) Experience is the bag of s*#t that we carry with us. There's no teacher like dealing with real issues. And if you survive them you're stronger.
Depends on the person. I find that getting good sleep, vigorous exercise, and a clear direction works much better for me.
If you believe that you are building something you are proud of and writing code in a way that your co-worker appreciates, then you are a great developer. If anyone tells you otherwise, have an open ear and ask them why.
I teach people how to code on the weekends and I can confidently say that the ones who are more considerate and understanding tend to pick things up a lot quicker.
The strongest developer I've ever met was on the aspergers/autistic spectrum. Empathy absolutely is a boon in life and in work, but it's neither a guarantee nor a primary driver of success in technical fields
At an earlier stage, building my own sizable project helped me the most. I still remember writing bunch of Java code in the middle of Iowa when I was an exchange student, which ended up helping a lot of my friends course registration in my university and got great feedback about the UI of the program. I learned a lot, especially about all the basic system building, and the best thing was that it gave me the confidence that I am capable of building something useful.
Since then, one of my weekend hobbies was doing some fun project that does not need a whole lot of effort -- like making a simple dashboard for the family in Ruby, building a home automation bot in Go, writing some my own investment tool in Python, etc.
It's just the same as picking up another language or any other skill: there is no one path people learn it. The way I learned English was mostly by reading many books, and many other people learn a second language mostly by watching TV shows or talking to people. There is no set path -- although there may be necessary things people would need to do regardless to achieve high-level of mastery, like talking and reading in a language -- but one thing necessary is an incentive, especially a positive one, and building confidence over time.
Also, there are many books that discuss software design. The one that helped me most was "Principles of Computer System Design". Not all the parts are great, but reading the first few chapters & recommended books changed my software writing.
"Practicing Mindfulness: An Introduction to Meditation" [0] was very helpful even though I don't practice meditation.
[0] http://www.audible.com/pd/Self-Development/Practicing-Mindfu...
The issue isn't formal education, then, it's breadth of practical knowledge.
The thing that has helped me most, at least in that realm, is getting bored easily. Once I learned a problem space enough to be confident in my skills there I get bored, and move on to something new. Learning something new always involve discomfort and lack of confidence and "I don't know what I'm doing." So to mitigate that, you can try to pick somewhere that is adjacent to your skills.
E.g. maybe you can switch jobs within your company to working on the platform itself, so you learn a new set of tools and problems but still in same programming language. Or find an open source computer vision library and read the code and learn the tool chain, build some toy projects with it. (Contributing without work's permission might violate your intellectual property agreement, depending.)
More expansive thoughts on choosing something to learn:
* Choosing a technology: https://codewithoutrules.com/2016/04/27/which-technology/
* Choosing a side project: https://codewithoutrules.com/2016/09/09/side-projects/
The only exception might be discrete math, but pick up a copy of Rosen or Epps and some Schaum's Problem books and you can pick that up as well.
It may be daunting at first, but its not magic ;-)
Congratulations, you're a developer. That's already miles ahead of what your typical highly-paid web developer writing CRUD apps does for a living.
To answer your question though, I suppose you're truly a developer when you have the mindset that you can learn anything required of you to get the job done.
My advice: pick a language highly dissimilar from C, and deep-dive on it. Then do it again with another language. The confidence you'll gain in the process will be tremendous.
For me, I've always had the privilege of being a lone wolf, because I only accepted remote gigs as a consultant as my primary goal was always generating revenue on the side through programming business ideas, trying them out in the wild, falling on my face and getting up, some things worked some things didn't but it eventually freed me up to only focus on my ideas as the revenue kept climbing. This independence forced me to be practical and efficient while focusing on hardened architecture, doing the work of many as an individual simple because there are less decision trees so things move very quickly.
There is a huge value in gaining experience and knowledge while working with great individuals in teams that make you better for sure, not discounting that experience at all. Just personally, I get very uncomfortable when people dictate practices to me that are highly crufty and theoretical so I'm much better suited going at it alone because I can't shut my mouth about those things and end up pissing people off.
A year and a half ago I moved from a large enterprise to a small consultancy who practices pair programming. I've learned a great deal more in that year and a half than in the preceding five years working solo on agile and not-so-agile teams.
Good practices and spending time attacking problems together with various colleagues across different projects and tech stacks is what has gotten me to that next level. I'm completely sold on the practice.
I'm much more productive while working with a partner than I am solo as well.
As a beginner the "one thing" would be getting a job. When you're beholden to someone else you lose the ability to freely cut scope whenever you're uncomfortable. Thus, I became acquainted to a "learn or fail" mentality.
Eventually I got stuck in the intermediate developer quagmire - basics are too basic but advanced concepts are too advanced. I knew I needed to learn more but I didn't know what I didn't know. Not to advertise, but Hack Reactor helped me clear this hurdle really fast. I walked away with a greater understanding of how to actually comprehend documentation and assemble applications in addition to the domain-specific material that was taught.
Now that I'm doing more meaningful work (though I'd hazard calling myself a "senior") my biggest growth points have usually involved having applications people actually rely on. I am my own pager-duty, so if I want comfortable weekends I need to write architecture that is capable of recovering gracefully from failures, errors that can be read by programmers or designers, etc. Answering to my users has helped me realize new ways I can meet (or exceed) their needs, areas where I was sloppy and should've handled better, and all sorts of things in-between.
I'm looking forward to the next point in my career that I take a significant stride in my growth as a developer.
and what would that be ?
1. Being able to code well. This amongst others requires (a) Giving a high-level structure to your code, way more than what a programming language and tooling enforces, and (b) Being able to maintain a "stack" of what you are doing at any time as you think at different scales, down from what to name a variable, to the project goal.
2. Think of a project idea of your own. Whatever it is. And then make it. You may realize very shortly where the gaps are, in your own skills or in the state of the art in technology. Having a good knowledge of both, the possibilities and limitations leads to a better understanding of how to do what is practical at present.
3. Master presentation skills. These are useful not just in presentations, but in all communications. I recommend taking formal training or reading a book or two on this. Like everywhere else, training and coursework on this often misses the point itself. So pick carefully.
4. Be watchful of opportunities as well as politics at the workplace. This point may seem out of place or obvious, but it may end up being something of critical importance in your actual growth path.
5. Last but not the least, know what you want to do, though be always prepared to adapt to the changing industry needs.
Edit: I assumed you are asking about a book on presentation skills, since that is only place where I had mentioned books.
I have also come across a good book on surviving corporate politics, that taught things I had learnt the hard way. I do not remember the name or title, but an Amazon search should help to find a similar book.
What I've learned is it's about the amount of responsibility you get. If you're responsible for something, ideally something critical to the product, you learn a lot delivering that product. That's how I grew anyway.
'I know you're the guy saving the company and all... but my printer is jammed can you take a look?'
You're able to make better mental connections and decisions when you're well rested, ultimately leading to growth as a developer.
Presenting at conferences. Being able to distil your work into 15 minutes is a huge skill. It forces you to think about the problem, how you explain it to people, and how to convince them that you're right.
You don't have to be great at the start - find community events which are welcoming to first time speakers.
I guarantee there's a meetup somewhere which is interested in vision algorithms.
At the very least, you'll have some smart-arse come up to you and explain why you're wrong. At best, you'll have people coming up to you with helpful suggestions.
As a bonus, being an active and visible part of a community is an excellent way to find your next job.
Often you will know that a piece of code should be refactored or needs better tests; or tests at all. It's always tempting to not fix stuff or rewrite as you go because this isn't the core of what you've been asked to do. If instead of taking the "easy" option you are constantly making the code better and simpler you will by definition be a better programmer.
Write a lot of software. Get code and architecture reviews from people with a lot of experience. Look back over your own code with an eye to editing it. Where can it be tighter? Where could you avoid a class of bugs by putting in a few habits?
Read a lot of history of computing, especially off the path that led to your primary tools. It provides a wonderful perspective.
And now the weird one: learn applied behavior analysis. It gives you the underpinnings for reasoning about the behavior of humans and animals.
Think of a simple pong clone. Add better AI. Maybe make a selectable difficulty of that AI. Make a GUI menu for that. Add touch or mouse controls. Add network multiplayer. Simulate better physics. Add sounds and background music. Online high score list. Etc.
Each of those requires increasing your breadth of knowledge, and doing them well will require some depth, too.
The second part of my answer would be to not get caught up in perfecting any of the above the first go around. Iterate, learn, improve.
I was a sole developer for a time, but we had the intention to grow. In preparation I spent a lot of time cleaning up an old codebase to best practices. I pushed every tool and library we used to the limits to get maximum benefit/introduced complexity, which meant reading and understanding the source.
My go to language is Scala, and I learned a huge amount from SBT, akka, slick, play and others.
Were now up to 4 developers with no official hierarchy, but its agreed that these investments have paid of.
We were working on a fairly large new system and I had an idea about how I wanted to do something. We discussed the pros and cons and afterwards he sat down and said to me "If you do it like this you'll have problems when you want to refactor it in the future, but if you want to do it that way go ahead". I went ahead and did it my way, he was exactly right and I learnt a very valuable lesson in application design, architecture, and how to lead people in the future.
I like to think that now in all the teams I lead that failure is always an option.
Writing (33%) and connecting with people (33%) is as important as coding (33%) - being able to program alone solves 95% of the 33% coding pie (being able to understand advanced concepts solves the other 5% of that 33%). You will never be "confident enough" to call yourself a developer. I have a BS degree in CS and I sweat my pants when it comes to code interview. Everyone has some sort of impostor syndrome. Write about what you did, and see what channels could connect you with the people who might be interested in what you do. There are always people interested in your work, no matter how stupid your project sounds to someone, keep in mind, [a person who isn't even good at playing games but has an anime voice](https://www.twitch.tv/nyannersz) has 250K people paying her every month to do it. You don't have to shill and spam other channels, but your intention and code, if not published are just your shit, no one cares.
Connecting to people doesn't have to be face-to-face. What I learned myself was that the Internet made it incredibly, incredibly easy to get to a very good person in the field who are willing to talk to me, even if I'm just not "very good." Opportunities will come to you by connections to such people.
Also, I think coding/writing/networking is like going to the gym, the returns compound.
Personally, working on side projects. I've started quite a few of these, but never had the patience to go through with them (or I stopped working on them as soon as they were good enough for my needs); and one day I discovered projecteuler.net and fell in love. The goal is to solve mathematical puzzles by writing programs that run under a minute. It tends to be short programs, and you have to have some mathematics skills. What I got out of it:
* finally putting my CS classes to use: when you're working on large numbers, which is usually the case in PE problems, you immediately see the difference between a O(nlog(n)) and O(n^2) algorithm - one finishes quickly, the other hangs your PC. It really gets you thinking about the efficiency of your programs, how much memory they will need, how you can optimize them...
* learning or practicing common programming tactics such as recursion, DP, memoization, etc.
* learning Python: writing short programs is a great way to understand how a new language works.
Obviously PE problems are toy programs, you won't be learning much about how to architecture your code or use a given framework, but it may help you build your confidence on CS topics, common algorithms, and math knowledge (which I feel more developers could do with).
This might sound a bit counter-intuitive, but learning how to break things has helped me the most in learning how to create things. I'm not at an absolute expert level in the IT security field, but it's the thought process that has helped me build a deeper understanding of how things are developed. From this, I have learnt and continue to learn how to think critically about whether a particular design for a piece of software I'm trying to break is good or bad, and also think about what I would have done had I been a developer.
I guess in a sense, it's me asking myself the question of how I could personally design quality software at all levels. Getting into the nitty gritty details from learning how to break things has really helped me learn more about development at all levels. From the low level, where, say, Java might have a function that could be used inappropriately - questioning why they were designed that way. To libraries that have issues - questioning why the developer used this library. To the high-level, the overall pieces of the system - questioning if they interact with each other in a logical way. Then there's also the user interface and experience aspect.
So, understanding the reasoning behind choices and why things are the way they are (from the level of the C programming language, to the libraries you use, to how the users expect to interact with it, and what other developers would expect if you want them to contribute to it) is the one thing that has helped me become a better developer. It just so happens that in IT security, you tend to ask yourself and the developers you're working with these exact questions.
I don't think it matters what you build, but a larger project gives confidence and much broader knowledge than you'd get in a work environment. Finishing bigger projects helps you build software engineering skills that are valuable but hard to develop otherwise.
https://www.findlectures.com/articles/2017/01/22/Software-Ar...
I think there is a fair amount of detail there, but if you have questions I'm happy to elaborate :)
Apologies if I missed it, but what's your general strategy for crawling? Is the list of sources curated or are you looking across the whole internet for content?
In a lot of cases I'm trying to rely on someone else having vetted speakers. E.g. a conference picking speakers, universities hiring good professors, someone recommending a talk on hacker news. I also boost the ranking if a speaker is interesting enough to have a wikipedia page.
I don't have a proper CS degree. In my first job, I was writing software based upon what I went to school for, because I happened to also know how to program. I kind of felt the same way you did. I was there in one capacity or another for about 4 years.
I had to change jobs for various reasons, but when I did I learned a lot of new things in a very short time. Skills and knowledge are important and I learned a lot of them, but most important thing I learned is that I'm actually a lot more capable as a developer than I thought I was. That's been very important for my growth, since I have confidence to attempt all sorts of things that I never did before. I would have done it a year earlier if I knew exactly how employable I was and what it would do for my skill level and confidence.
If you feel held back by the work you're doing, I suggest you change jobs. If you're not and you like where you work, then the next best thing to do would be to start a side project that doesn't have much to do with what you're doing now. That's harder but it's a way to pick knowledge up.
I already had several years as a software engineer, but I was shocked at how much programming we did before we got to the "mutating assignment" statement: set!.
That class and it's follow-ons in that program did a lot to expand my mind about programming and thinking about data. I later used the curriculum to introduce several other self-taught programmers like you to a more rigorous, data-oriented way of thinking about programming.
You can work through the curriculum yourself here: http://www.ccs.neu.edu/home/matthias/HtDP2e/
Career-wise, having 3 years of experience and a Master's Degree in a hot programming market like Boston opened a ton of doors for me.
Why are you not testing your algorithm in your computer? Load pictures, make it run through your functions, see the result there. That's why you have ifdefs. Then you can use libraries, malloc, to get to the point where you can test it
Why are you automating anything in bash? In python? yeah
Doing parallel projects help
I think these arbitrary and frankly elitist constraints on what it means to be something like an engineer is often time more bullshit than not. You _are_ a developer. And you might even be better than you think you are given you've had to work with a very difficult language with extremely difficult constraints. Personally, I have no idea how I'd work in C if I didn't have access to malloc, free, or a lot of the components of the STL. The fact you're still looking to grow and expand experience rather than settle into dogma and specialization shows a lot of maturity.
If you needed an official welcome: Welcome to the club. We're all different here.
Beyond that, job hopping. I have written software targeted at other software professionals, physicians and nurses, lawyers and paralegals, military and coast guard pilots and ground crew, rocket scientists, and military paperwork bureaucrats. Each time, it stretches out the arms of my "T-shape" a bit more.
Nothing hurts me more than someone telling me that I can't work from my own initiative. "Do this, do it exactly this way, and do no more." That's guaranteed to stifle my personal growth, and to preemptively discard much of my expertise.
It changed how I think about writing code by exposing me to new ideas and shining a light on my own bad habits picked up while learning by doing without understanding.
If you're writing C, then you're a developer, no doubt about that. But if you're interested in the 'meaning' of programming and software engineering, then I highly recommend learning functional programming. Here's an excellent course: https://www.coursera.org/learn/programming-languages/
Confidence. You are only as good as you let yourself be. Believe in yourself more. Don't let your worries block your development.
Forgiveness. Forgive yourself for mistakes and not knowing things. As that DHH viral Twitter thing showed, even the best and most productive developers Google the basics all the time
Challenges. I grew the most as a developer when I had to do something and I needed to get something done. Be it a side project, new job or saying yes to something a little out of your comfort zone, challenges help you forge ahead with purpose.
It's often why books and courses don't get you that further ahead on their own. It takes that need to fix x or implement y to really develop
It was sitting in the junk pile, with a cash value of maybe $700 if we were to sell it on ebay. So I asked if I could use it, and they set it up for me.
I had never configured `/etc/network/interfaces`. I had never used the `ip` or `route` commands. I never knew what would happen if you tried to `traceroute` when your gateway is misconfigured.
Now I've done all of those things :)
For me, any opportunity to get my hands dirty on something I've never done before, I jump on. I have taken jobs because of that one criteria. If I'm not growing at my job, I either take action (talk to my boss) and make sure I get new opportunities, or I start looking for another job.
Make things. Make things. Make things.
Not just pieces of things, the full things!
Don't get trapped in over-specialization, always be able to make things completely.
Whatever notion of "full-stack" you have right now, you have no idea how big the stack really is until you try to own it and make things on your own.
Also, and this is a big one, to be a truly great developer, you need to transcend "developer" and understand and master the context in which "developer" exists. Let's call that "growing your stack". You will be a much more insightful developer when you see all the moving parts, of which development is just one.
Workign through things like this really gives you a lot of confidence. There are a lot of resources online for this stuff nowadays. If there's something you read about that makes you go 'wow, that's impressive', define a manageable subset of the subject, and go do it!
At the beginning, I wanted to hack on simple things like creating a blog or twitter clone which pieces of can be found in tutorials. As you get more experience you can build increasingly complex things in shorter time spans.
http://norvig.com/21-days.html
Work on a project where you are the best programmer; work on a project where you are the worst programmer.
Peter also stresses "deliberate practice," a point I did not appreciate until I read the book "Peak" recently.
https://www.amazon.com/Peak-Secrets-New-Science-Expertise-eb...
With this given, I recommend you give yourself permission to fail, so that you may grow, and take on a stretch goal. I've done this a number of times. I'd gladly share more with you if it were of interest. See my HN profile to contact privately.
In a more general view, having skilled peer developers that have extensive knowledge in the field I am working on and are willing to mentor. I did my BS in a dual system that consisted of half a semester studying and the other half working in different teams of a software company with ~150 devs. During this time I had two or three very good mentors who not only made sure I am doing the right thing but also showed me how to do them correctly. This meant mainly reviewing the architecture and code I came up with and telling me when I was doing bad practice and how I should do properly. I think the situations I learned most in my whole studies were when one of these mentors refused a review or help me some higher level problems until the flaws they found in my code weren't fixed. This made me develop a feeling about if the approach I'm taking might be a bad idea and what to do instead that I can most often trust to a certain degree.
The other thing is to go beyond the basic tutorial steps for advanced technology like datastores, queueing systems and such. To me, this works best when I have the option for using them for a certain case that is (or will be) more or less important for production. I think gaining brief information about different frameworks etc. without wasting too much time before you need them is very important to know your options but you only fully understand the characteristics and problems behind them once you put them to an extensive and got hit by their pitfalls.
Second, it helped me grow from always late to (mostly) always early. No help in sharing a design after the feature implementation is already started. It's either time lost on whatever was done already, or time lost discussing how to adapt it so it fits. You should discuss before you start, so as an architect that makes you responsible to prepare before that moment and facilitate. Be sure to discuss designs with your team(s) though, don't go all ivory tower on them.
Third, it forced me to grow in the social aspect. I am only as helpful as the information I can bring to the engineers in my team(s). I learned I have to understand the individual engineers, how they work, their strengths and weaknesses, their preferences. I learned that showing genuine interest in them and their wellbeing is a great way to achieve this. I have never feared the coffee corner or desk/room/lunch talks so it was mostly paying some additional attention to their responses, talks, interests, etc. I daily use this information to select the right person for the job, adjust my explanation to fit their needs, learn who likes more intervention and who I should (and could) simply trust and run free.
Frequent, real business and engineering challenges. Exposure to a variety of people in organisations from the Netherlands to Silicon Valley, at startups and multinational corporations.
There is no substitute for this kind of learning, and I am so thankful I was able to do it.
Do you mind sharing what is the result you are after?
Edit: I don't mean you will completely stop a process, but rather some kind of checkpoint to measure your progress.
Start building things. Pick some open source projects you like, dig into the code, and try make a better version of them. Also stalk (or if you like, talk to) the creators on Twitter to learn how they think.
Do this consistently and in a few months you'll begin to be embarrassed by how bad and inefficient your previous projects/processes were.
That's when you'll know that you're growing.
In a professional setting, this would equate to a job that allows a certain amount of variety. If you can't, in your current role, you should move!
It doesn't matter what the variety is. If your given variety you will grow. Different variety, different direction - but nevertheless, grow.
If you're curious, I wrote quite a bit[1] on this topic.
[1]: https://nickjanetakis.com/blog/have-you-hit-the-point-of-dim...
I highly recommend consulting early on in your career to do that. It can be stressful but once you're used to it you will lose the fear of the unknown eventually.
If anything, the take away is that your "break" could come from almost anything including random chance, or being thrown into a situation for which one is utterly under-prepared.
Building human-first systems is the only way to go. (It informs stuff like project management, too.)
https://www.instagram.com/zach.lieberman/
I have learned a great deal from the act of daily coding and treating code like a creative medium without any pressure on what I make or why. I found myself tackling hard challenges so I wouldn't get bored and learning a variety of new tricks to help make the sketching easier. I wrote about the process here:
https://medium.com/@zachlieberman/daily-sketches-2016-28586d...
I think daily activities are the best for growing -- short, concentrated, and limited in scope and can fit with the rest of your life.
I know this isn't something specific to programming, but it's the one skill I can point to and say "this is something that has helped me every day." Being able to clearly and confidently articulate my position. Being able to put myself up in front of people and share ideas and potentially be wrong. Being confident enough to ask for help.
I'm never going to learn everything, but this one skill is something I feel is invaluable whatever career you choose.
My first job I was the only developer (until I got to hire a junior), and learned a lot by trial and error.
But I quickly made a massive leap forward when I moved to a team of a dozen developers, all of whom had knowledge, skills, experiences or ideas I could learn from.
Specifically for me, it's been reading. I used to not like reading source code. I often wouldn't know what I was looking at. If I found the style strange, I wouldn't know if it was inherent to the language, the project, or just the developer. Just knowing library X can do T doesn't always answer the question; sometimes you have to know exactly how it does T, with what tradeoffs &c. Same goes for APIs. Reading has brought me more learning than anything.
2. Find a mentor - this is the fastest way to improve. I have 5+ years of experience in frontend development - lately I've learnt a friend how to work in the frontend development and after one year he know almost everything that I do (I don't want to talk here about dealing with specific quirks and/or development problem solutions by programming because it is something that You'll eventually achieve with time) but yea, I was learning by trial and error and he wasn't wasting so much time like me because I've told him everything before he even tried.
That and just having a passion for writing code.
Before that, I was always reluctant to speak up, or express any strong opinions, because I was always surrounded by people who appeared to have their shit together and were very confident and forceful about expressing their opinions. I've probably overcompensated since, but finally allowing myself to feel that freedom to just say, "No, I think that's not the right way, we should try this instead," has allowed me to progress much farther than any technical achievement I could name.
Responsibility, there's nothing quite like it. Responsibility for code being shipped to production, responsibility for a terrible bug you shipped, responsibility for completing a new feature.
We learn by trial and error. But I think you already know that. I think what you need (to paraphrase the Wizard of Oz)... is a piece of paper that says you are a developer.
You know how you get that? You write it on your resume. That's it.
To be a developer, you call yourself one. Period.
To be a good developer, and one that people want to hire, you have to to have the experience. And it sounds like you have that. Different from mine, different from other peoples... but you have it. Look for new positions that need your skills. It's a great way to grow.
I love PHP. I think it is underrated and most people and companies prefer Ruby or Python. Those are great languages.. but PHP can do just as much. So I know some Python.. I could probably switch and write code in it, but I just prefer to code in PHP. As for Ruby, I longed to learn it, spent some time understanding it and while it is okay, my preference just returns back to PHP.
Sure, it is best to learn the languages in demand, but I'm strong and proficient in PHP. Why not stick with what I love?
In my version of the world; most people tend to specialize and know their area very well; but often do not know the breadth of technology very well.
If it is an option; you can try to go back to school for a programming degree. Or you could go to a conference for something different than your day to day job. Or you could work on an open source project using different technologies than the one you work on in your day job.
May the force be with you. ;)
But doing something new under the instruction of someone who knows it well, you can ask WHY they do things a certain way, or what would happen if you did X differently, or even just "help, it's not working at all!" and learn a ton from the answers.
So access to 'good' GitHub repos has been a godsend.
Also knowing how to build web connected GUI apps in an afternoon is also a very liberating skill for a developer (Python, Ruby, Clojure are all good choices; or C#, Java if you wanna stick somewhat closer to what you know).
(Fellow Mech E degree holder here, but I've never worked a day outside of computing...)
Other than that, just experimenting with a project that starts out simple, following through with where it leads you not giving up and seeing how deep the rabbit hole goes has been instrumental in my experience.
Firebug, and a copy of Javascript: The Good Parts from the library.
These two things put together helped me finally grok functional programming, and really understand what was happening in my code.
You were flattering them I an extremely sincere way. So if they help you they can be altruistic, be flattered and call that work.
(2) Whenever I ran into some kind of bug/anomaly I would refuse to hack my way around it. Sometimes I would soend days getting to the bottom of something. Usually I was making wrong assumptions and this has helped calibrate my intuition and gives me a better sense of what ought to be going on under the hood.
thing.prepare_frobnicator()
thing.ensure_frobnication_ready()
thing.frobnicate()Development time matters, maintenance does not.
You can win an award for a program with 500 line functions that is vulnerable to SQL injection.
Copy and paste is a lifestyle.
Static analysis, unit tests, and repeatable builds are crazy talk. You will be treated as a pariah if you bring any of these topics up.
Version control is too complicated.
Catching all exceptions fixes bugs.
I'd start to find out why this is at your workplace. You're sure to learn something, either technical, in social skills, or with what not to do when negotiating a bureaucracy.
Hint: A good way to get most programmers to spend a lot of time explaining what they've done is to stroke their ego.
Without that trust you are just a coder.
The trust is necessary to be able to push your projects, extend deadlines and have a general influence on the shape and quality of the product.
Architecting the product is much more valuable experience than writing code from specification.
Example: write your own CMS, then look at WP, Drupal, Joomla. Write your own web framework, then look at Struts or Rails.
Then what you end up using is not magic but shortcuts that you can understand and sometimes improve upon.
Knowing multiple languages can let you get a wider range of gigs and help out when making decisions on what tools to use for new projects.
I knew all about "second system syndrome", but I still did it. The new system would be more general, more configurable, more efficient, use exciting dynamically created code... It was a disaster. Now I know not to do it again!
I learned a lot from HN, much more from side projects. But a mentor helped me clear the chasm between "writing code" and being a software developer.
Honorable mention goes to quitting my job (with savings) to start doing development and data science consulting full-time.
I'm self-taught and the person who created those projects was likely educated. So taking over their code was a massive and instant dose of knowledge to me.
Ability to search other people solution, to read how they approach the problem, what solution is good and why is really invaluable. Also it saves alot of time, because usually google shows very relevant result.
(cf. http://thinking-forth.sourceforge.net/tf-kindle.pdf et. al.)
No matter the task or how hard it is, you can do it. Think about it and let it settle in your mind, YOU CAN DO IT.
When you face IT projects and challenges with that set of mind every thing else just falls in place, the only thing you need is challenging projects, find those either at work or outside of it.
Best of luck.
I'm still going to throw in: spending all day reading Hacker News. just kidding!
HN noprocrast has been more helpful than that.
To many folks call themselves developers because they can write code. The old saying: "Jack of all trades, master on none".
Also being forced to understand a large codebase, and from that understanding why the 'best practices' were put into place.
i can't possibly overstate the paradigm shift in my thinking afterwards. (not clear if that just speaks to the degree that i was misguided)
a more recent development was forcing myself to rebuild my shopify store using webpack/ES6
"Master Practice in order to create Mastery through practice"
Write/Re-write/optimize is a good cycle to be in.
What did I learn? First, to resist giving up in the face of fears over lack of skills/experience/knowledge or lack of ability to acquire skills/knowledge. Then, to ignore it altogether. Finally, to turn that would-be fear into a motivating force which helps me to focus in on achieving my goals.
How'd I get into all that?
As a second year CompSci undergrad I took a freshman Intro to Ocean Engineering course to fulfill an engineering elective requirement. In spite it being a freshman course, there was a rather lengthy team project. The goal of the project that semester was to build a device which could be dragged along the seafloor by a boat, and which would detect pockets of water with lower salinity (salt content).
My role on the team was to build the sensor package for the vehicle. With ample help from an excellent professor who specialized in water wave theory and insanely low-cost in-situ sensor development (shoutout to Dr. Eric Thosteson) I managed to cobble together a CTD (conductivity, temperature, depth sensor). I'm in my 30s now, and I still remember all the little details of that project to this day. It used a PIC16 microcontroller, a simple pre-calibrated 5V linear analog temp sensor (0.1V = 1°C), a $15 motorola linear analog differential pressure sensor (one side reads pressure within the sealed box, the other side I filled with glycerin and capped with a semi-permeable membrane and reads the pressure of the seawater), and a 'homebrew' conductivity sensor made from a comparator-based relaxation oscillator, where two titanium wires exposed to the seawater serve as the measurement cell, acting as the resistor in the oscillator circuit. The oscillation was balanced around ground so that current flow would reverse with each cycle, minimizing the impact of electroplating on the probe. The sensor package communicated via a tether wire back to a computer on the boat via balanced RS-485. Before starting this project I never knew that these things existed. The idea that I could now write code which executed on a single chip which I could then build into a circuit which does actual things in the real physical world, and that I now had the skills to do this all on my own was crazy exciting to me.
The project made me consider a variety of crazy things and learn a bunch of new skills (drilling acrylic for sealed cable glands is a huge pain). However, I think it made me realize one very important thing: that fear I had over not being an expert already and the worry about not being able to grasp new skills were completely useless.
After the project I did what I could to stick with Eric, the professor who helped me out on that crazy project, and worked as an engineering assistant on any projects he or his grad students had for me. The fact that I could write good code was a huge asset, as most students in the field are already learning so many other crazy things that they can't devote the focus/attention required on learning strong software engineering skills. After doing some grant work for a nonprofit oceanographic research institution, he was asked to come on as a full time employee. Since I'd been assisting with that work, I managed to come along for the ride. The pay was pretty bad, but the experience was priceless. I could easily fill a book with the lessons it taught me. But really, it all just served to reinforce that one big lesson I learnt back on that undergrad project.
Having said that, code reviews are also an acid test if you can communicate well. They're more intense than most interactions, and much easier to screw up. Second opinions/having a mentor review the code review if you're completely new to it is recommended and might save one or more relationships.
I am a serious developer
Reading code is quite different from reading text be it fiction, non-fiction, poetry or prose. One striking difference is code is not optimized for (human) reading whereas books are (at least the good ones). So trying to make meaning of code requires a true companion to reading (and comprehension) - imagination. I found it immensely changes the speed at which I could absorb content when I could build a mental roadmap and try fit things in. So if I was reading code that dealt with a new domain like MRI/PET scan imaging software, I started with domain knowledge first and then followed the code to draw parallels. That helped me build a mental model of how the code modelled the problem domain(e.g. window width/level, reconstruction) to familiar software domain (pixel values, approximations). Now once I had these 2 mental models and how they are connected. I would try and implement them in small independent ways and then combine them (the unix way if you will). Once I had a decent grasp on these two models (i.e. I could explain the domain concept to at least 2 people - one who knows it already and one who does not and visualizing the program execution in my mind) I then slowly added more details to my mental model.
This however, was different than the first step. Now when I read more concepts, I first try to fit it in the mental model that I have, imagine how I would implement it and then actually see an implementation of how it was done by someone else. Usually I come up with better solutions but thats because I am ignoring some constraints that the developer(s) had.
So after a few iterations, you'll subconsciously built great organized mass of knowledge that you can add to or draw from. This one slow, hard exercise had improved me as a developer more than learning any new framework or language. These days I am not the first to jump on to the next shiny thing but once I do decide to my progress is way faster than what I had before and as compared to others giving them the impression that I am a fast learner (which surely I am not).
So a satrical way of stating this is to be a better developer, just write more code, which although partly true does not make sense unless you realize that your primary asset is the mental models you have built over many many hours and years.
What i struggle with most is to keep up with the rate of new information available and the consequent higher demands of filtering it out and the physical limitation of my memory (I cant remember every detail of everything I have learnt) and these models are complex enough that I must spend time to write notes in a way that they are optimized for fast reading without losing too much detail.
So yeah, off topic but that one thing sure did make me a better developer (in my opinion).
In 2012 I got my first internship at Intel to work on post-Si validation for atom. I remember there being a huge amount of build up in my mind leading up to orientation, "What should I wear? Should I look up how to act?" etc... On orientation day, after all the usual cheerleading, all the other interns waited in a room for our managers to come pick us up and give us a tour. It felt like we were waiting to get new families. I saw each intern get picked up by smiling, charismatic managers, all happy to see them, one by one. My manager never came as he was too busy and I was told to just come back in the morning and I'd get a tour.
So the next day, I did, and our meeting seemed forced and hard for him, but he was really trying to make my internship seem like a "thing". Then all the interns who were in my section were given a tour of the lab and shown basically what they were working on, the different projects going at at the time. I remember being very concerned about what I was going to work on, what I was going to "be" so to speak, eagerly listening to every word, hoping to catch anything that would impress my superiors. Then there was one thing that caught my eye, a robotic arm, barely draped in a cloth, that just looked neglected.
After the lab tour and lunch, I met my mentor, a lead on the team, and we (me and two other interns) were to be assigned our work for the summer. This, it felt, was the moment I had been stressing over. They were each given duties, but when it came to me it felt like my mentor didn't really have anything in mind yet and so something inside of me just blurted out that I wanted to work on that robot that I saw in the lab. He told me a story about how it got to be that way and how no one was really in charge of it and that for now I could start just by figuring out how it worked and could take it from there.
I ended working there with almost complete ownership of my own project, just straight up coding non-stop, for what started out as the summer but then extended into a co-op that lasted until I graduated. Having something to work on, with very little structure, every day, was so much fun you wouldn't believe, and it was there that I developed the foundation for all of my programming skills.
I took that project from one machine that turned on but didn't do anything to two machines that could calibrate themselves, move through an arbitrary topology using pathfinding, pick up parts, take pictures of the different serial numbers and identify them in a database, and cycle through the remaining parts in the tray with very high accuracy. Each component in this ecosystem was networked so there had to be fail safes, like you don't try to move to the motherboard socket, if the actuator is already down, etc... and there were a lot of components. The only thing missing from this that would have made it a complete continuous integration system for Silicon was a test runner, which I would have had no idea what to do for back then. Any way, although I was a software intern, I even got to build a safety cage with an interlock, complete with a hardware-based fail-safe switch, for the robots, out of extruded aluminum! To be honest I didn't really know what I was doing the whole time, which is why it took me over a year to do this, but it was such an incredible learning experience that I will cherish it forever.
My manager, team, and everyone at Intel ended up being really awesome to work for and the internship was awesome, even if it wasn't a "thing", but hands down the best part of that experience was just figuring out what to do with myself and then becoming deeply and passionately absorbed by it and coding nonstop.
I languished in one place for many years and when I left, I learned a whole lot in just a couple short months. There's a difference between "knowing of" a practice and working among a team that lives and breathes a set of practices every day.
This more than anything will introduce you to the various styles of 'pro code' that people use, at least in terms of formatting. And if you can pick out the good one's you'll see how a pro project is organized.
2) Learning more than one language
3) Cloud
My raspberry bush is the biggest thing I've ever let grow.
Inside the house would be my gorgeous aloe vera pla y
gamedev helps with that because it's much easier to call it a day and start another game.