Ask HN: I am busy with too many things at once
A couple of years ago I realised I was a mediocre programmer. After 5 years of work experience with unfinished degree I knew only one language (php of all...) and some good practices on a surface level. I set that for change. For 2 years I studied in my spare time, learned a bit of Java, go, clojure, learned some fundamentals and good practices classics (gang of four, DRY) started reading blogs and following the industry.
Except, it's too much. I realised I am into too many things. I know a bit of everything, but not too many things well. I want to study data science, maths, devops and find that my desire is driven by fear of becoming outdated and irrelevant. I would appreciate a piece of advise on managing the learning process, get the joy of tinkering back and conquering the anxiety of ever changing rules to the game. Thank you.
121 comments
[ 45.1 ms ] story [ 3219 ms ] threadBut the main focus should be to get something working.
If that is your genuine concern, I'd suggest focussing on timeless topics. Two easy rule of thumbs: (1) if it's been around for a while and still relevant, it's probably going to stay that way (eg compilers/parsers, operating systems). (2) if it's hard and math-y, it has a good chance at staying power, even if new.
In any case, do what adyus said: pick one thing, and ship, ship, ship.
Some inspirational reading: Peter Norvig's "Teach Yourself Programming in Ten Years" (http://norvig.com/21-days.html), Richard Hamming's "You and Your Research" (https://www.cs.virginia.edu/~robins/YouAndYourResearch.html). Or if you are of a more entrepreneurial bend, P.T. Barnum's "The Art of Money Getting" (https://www.gutenberg.org/files/8581/8581-h/8581-h.htm)
Happy to talk in private. My email is in my profile.
(Some snark thrown in for free: forget about OOP design patterns.)
But most devs don't want to be in those positions :) Cause it involves a bit more people wrangling than code wrangling.
1. Learn GoF design patterns. Be amazed by the cleverness.
2. While learning others languages, discover that other approaches remove the need for GoF design patterns at all.
Example: Visitor isn't needed in a language with double dispatch (like Lisp). Chain-of-Responsibility is just foldl. Factory for dependency injection is just a closure or a partial function. And so on.
If you are in luck, a language gives you first class support for abstracting new patterns. (Eg in assembly a procedure is just a pattern and convention, most modern languages help you by providing procedures. Same languages are very good at being extended. Lisp is a good example, and so is Haskell. Even Python is great in that respect compared to, say, Pascal.)
I am still trying to figure out what dependency injection really is. It's seems like only the Java guys have a need for it, but they rave about it.
foo() { service = someRemoteService(authn, authz); http://lookingglass.internal.adm.bol.com/?page=TAM+Middlewar... }
is replaced by
foo(service) { do_something_with_service(service) }
It makes replacing service with fake_service_object easier, thus simplifying the test process.
Common use case: If your service was a remote database, you can replace the database handle with a mock object which pretends to be a DB but is actually a simple object returning hardcoded values.
Deadlines provide constraints. Constraints help with prioritization.
1. It's always changing
2. Feel confident in that something that you learn will become relevant again
3. You can't know everything
In addition, find a team that will help you learn and practice everything you are interested in. Look for a company/team where individual engineers have to wear many hats.
I think this is a good question that everyone at some stage of their life will need to ask to grow beyond what society and peers demands of you, but don't make this out to be the silver bullet like I did because I'm still on that path and I have no idea if I'm getting any closer to an answer... damn! hehe
My eyes are bigger than my stomach. I believe that these days it's probably impossible for anyone to really understand everything.
Personally, I think PHP is a fine language when coded well (most of my PHP looks like my Java, though I haven't coded much PHP since just before the introduction of lambdas). I feel like it undeservedly gets a bad rap, perhaps because it's so easy to write horrible code in it. But that is just evidence of its complete accessibility in my books. I think that some of the coworkers I had at my PHP jobs would agree that it is an adequate tool for the job of web development (some people even use it for other purposes, but that's not my style).
I wish I could give you some solid advice, but I don't feel qualified to do so. I will say, however, my favorite experiences in programming have always been upon completion of a project -- seeing it go live, get real users, and actually work, from start to finish. Most of those times have been in my professional career where I was paid to complete something and had a hard deadline (that has nearly always slipped), but a few have been school assignments and personal or open-source projects that have 0 or nearly 0 users. Sometimes solving a problem or scratching an itch is just the thing I need.
Also, in nearly every case where I've shipped production code, I look back on it fondly some years later (especially if it is still running and getting used) and think, "damn, I must have done an incredible job. I got everything just right." But on the rare occasions where I get to look back at the source code, it's always got plenty of TODOs lying around, and things I wanted to fix, stuff I would do if I had a bit more time but just never got to, etc. It's never perfect... but sometimes it still works. Memory is a funny thing.
Finally, someone linked this on a vaguely similar thread recently: https://www.physics.ohio-state.edu/~kilcup/262/feynman.html - I thought it was great.
Here's that thread, BTW, which you may also enjoy: https://news.ycombinator.com/item?id=9796203 -- some really quality responses on there, IMO.
Feynman is a lovely example to follow for anyone wanting to become an engineer. The book is one of my all-time favorites.
Also, this http://www.bothsidesofthetable.com/2015/06/19/why-successful...
Write a production-ready library in a language you are interested in, complete with unit tests, follow best practices, write a set of good documentation, etc. for it. Put it on github, in the language's package management system, and see what happens.
Finishing stuff does really feel good.
I notice that in software industry there is common recommendation of doing some project (or just hack something) to to learn or get better at something. This advice I think is solid and is generally good for many people.
However, I feel that it is not valid or valid only in very limited way to some people. This all depends on character types I guess. E. g. myself, if I ever tried following it I would not get anywhere, because projects for the sake of projects is something my mind has big problems with. It's simply not in my nature. I would argue that regarding this point I am part of silent minority in IT industry since I noticed quite a few developers who are similar in this regard.
So what is alternative if projects/portfolio/... might not be a thing for you. What works for me:
1. Concentrate on Theory. This addresses few things: I must understand theory to not get frustrated, I m more interested in theory than practice in general, Often theory is just enough and mind will just find solution when you need.
A. Concentrate more on studying theory.
B. Use micro-projects just for testing and understanding concepts, not something useful by itself.
C. Study "best practices". To compensate for project problem.
2. Look for a way to have goals (projects) forced on you. Addresses few things: it frees your mind from over-thinking (e.g. "whats the big purpose of this?"), it must be done - you cannot just quit when lose interest/reason-to-continue.
A. Hobby. Join online courses with assignments, university (if it allows).
B. Job. Try to look for positions with more "projects".
I think it boils down to weither you keep track of all your projects (what's to be done next), that you do not try to plan ahead too much and that you do not plan too many tasks for a single day. If you stick to these guidelines there is a high probability that you get a good experience ("did that, finished that") every now and then which keeps you going.
I've often found that if I tried to do something because I thought it would be good for my long term career prospects I just wasn't that motivated. However I often found myself circling back to the same technology or topic at a later date out of pure interest and was highly motivated then. Attitude toward what you're working on and your reason for doing it is almost everything.
Sounds like you're maybe feeling a little burnt out if I'm honest. It happens to all of us. Whenever it happens to me I either increase the frequency of my other hobbies I enjoy (water sports) or if its a particularly bad spell, try looking into some completely unrelated area of inquiry (for me that can be space, cartography, travel, electronics, brewing beer, etc - even learning a musical instrument). I find that it not only stimulates my mind again but ultimately I start to make new connections about how my existing software skills can be applied to this new area of interest. New project ideas start to flow... and off we go again.
I'm still a student, studying computerscience and I'm almost finished. The problem is, my fun in computerscience is simply limited, sometimes it really makes a lot of fun. Sometimes it doesnt (Majority, since I am really unmotivated). Now. The problem is, I don't have anything I'd consider to do for the rest of my life. Was totally clueless after graduating from school and I'm still unsure. This just doesnt sound like a good future, but I really cant figure.
For now I'll just graduate from university. Any Advice?
Getting passionate about something is weird. You can't make yourself do it. You can only discover it. The only way to discover something is to get off the sofa and go looking for it.
Edit: and for what it's worth, I found "computer science" as taught at university the most boring subject known to man-kind. For a lot of university courses, it's the antithesis of "hacking". I love making things and software presents us all with a creative canvas where the only really hard limits are our imaginations and in some cases, access to raw data. I dropped out of university after 2 years yet here I am nearly 12 years later at the peak of my game thus far and I enjoy the fact I still have a lot to learn and the field still has seemingly endless challenges to tackle.
The question that I keep coming back to is whether I am doing the things that I find interesting and engaging. The answer is an absolute YES. However, if I need to do something else where I would need to learn some other language, or technology, so be it. It is all part of the process.
My advice is to slow down, and focus on your interest and passion.
- I realised I was a mediocre programmer
- ... (I) find that my desire is driven by fear ...
The first is a good feeling :-) Too many programmers don't have this realisation. Embrace it!
The second is something that worries me slightly. All of the programmers that I know who are driven by fear let it chase them into failure. Getting the "joy of tinkering back" is what you need. Forget the "ever changing rules". Chase what you love and forget about the rest.
Now for some specific advice. You are at a level now where you need to integrate your knowledge, not learn bits and pieces. Stop everything else you are doing and start a major project that will occupy your time for the next year or so. It doesn't matter what it is, only that it is something you love. This will help you more than anything else.
That would be pretty hard if you'd be working on a 20+ year old legacy system written in COBOL.
Second, that doesn't subtract from the advice being correct. Sometimes the thing you need to do is just "pretty hard". Or, put reversely, if you never do things just because they are hard, don't be surprised when you end up in a boring and uninspiring place.
TLDR: Don't worry or feel the need to know everything. Pick what you love and enjoy working in and focus on that.
As someone who's been at it for years, I'll just give you one little piece of advice. If you've already been through the fundamentals, you've done enough. Now, instead of focusing on learning technology, focus on building things, this is what real engineers do.
Let me explain. You'll probably get much better with at least one thing once you ship a real project to the end, and this is where you'll get better.
One of the best programmers I've ever worked with was a PHP guy when I met him, and he was good because he shipped efficient, tested, and working code fast, all while being able to document and communicate about it with his team. That's what being a programmer is. You won't become a good professional programmer by chasing after hip technologies (even though learning different paradigms always help), but by building things, and preferably with people, because this is how things work in the real world.
As long as you stay with startups and technology companies, you'll see that any CTO or lead dev worth his salt would rather hire a smart Perl programmer with strong fundamentals who shipped things over someone (maybe smart too) who knows a bit of JS, a bit of Java, and a bit of Haskell. This is, however, not true with a lot of non-tech companies, where keywords on resume, a professional-looking attitude, and some good sales skills will usually get you better positions.
It's never too late, don't fear irrelevance, build things, and have fun!
How many job offers do you see looking for a smart Perl programmer. How many do you see listing 10+ technologies, plus experience in scrum? (Does doing a stand up every day make you better at it? )
You don't need loads of offers, though.
https://youtu.be/TCbFEgFajGU
- HR requirement that all positions be advertised externally, even when there is an internal candidate who is suitable and people are happy with (similar rationale for the H1B policy but at a smaller scale and less likely to engender foamy-mouthed rantings)
- hiring company is actually an agency who is fishing for CVs
And then probably you are Indian, and Indians from what I noticed are extreme bigots towards their own minorities, not to mention raping women is like national sport in India.
(Anecdote: I rejected an offer from a YC startup once because ~60% of the process was them fretting about me not having Ruby on Rails experience. I didn't (and don't) want to work for a CTO that doesn't understand that fundamentals travel between languages.)
As the GP said, any CTO or dev lead worth their salt would hire a dev with good fundamentals in the 'wrong' language over one with poor fundamentals in the right one.
You have to do some legwork to identify who these CTOs and dev leads that care about good fundamentals are. You'll need to engage with the tech community around where you are/want to work and talk to people. It's not a numbers game.
For sure. You can learn a new language in a few months, but not how to think like a programmer.
However, there could be an argument to be made for holding out for someone who is a good programmer AND knows the right language. Especially if it was a future leadership position. In the busy world of a startup, I may not have 3 months for you to learn Ruby / whatever language of the day.
If you coded in C for your business and two identicAL in every way people applied.. one only knew ruby and one only knew C.. which do you hire?
Ignore the laundry list of requirements.
By the way, these things are hackable, too. It only takes a bit of practice to become a better salesperson than most programmers, and only a small amount of effort to look more professional, too. (And a good suite can even be comfortable.)
More generally, by fundamentals I mean a pack of things including CS101, basic understanding of C (K&R), data structures and algorithms (those available in coursera courses are enough to get the basics), good use of source control systems, and project architecture basics.
+100. I did exactly this. After working for 12 years, took a break, learnt 3D game programming and actually shipped a playable 3D sport simulation game on iOS. Enjoyed graphics programming a ton. Also prototyped the game in Common Lisp before porting it to iOS.
End result: I now work as a scientific software developer specializing in 3D visualization all thanks to the graphics knowledge gained in the process of shipping the game.
So I would say once you have covered enough fundamentals, you must ship something you think is hard but just harder and not completely beyond you.
For me the fundamentals are: 1. Multiple programming paradigms 2. Algorithms 3. Data Structures 4. Digital Electronics 5. OS 6. Networking and 7. Math for CS. This will take a lot of time. I invested a lot in 1 - 4, skimmed 5,6,7; shipped a game and things unfolded.
Do you mind asking you a couple questions? Where are you based? How does the market look like and what kind of pay can you expect as entry-level/experienced scientific programmer (i.e. is it a significant hit pay-wise when compared to standard enterprise/finance/google developer career track)?
If you are at entry level, I can think of having a related self project or contributing to any of the numerous open source projects in the scientific stack will do the trick. Hope this helps.
As for getting a self project - I'm thinking of doing a physics engine focused on static forces - something inspired by structure engineering methods (solving with finite element analysis for example). I have no idea if I can make things bend or break believably in real time but it seems like a cool idea to pursue.
Watch ancient code of you in PHP and after all you learned, read it again. Was it really that bad code? I always thought the same like you did, but when i read old code... I sometimes think it's beautifull ( can't explain it otherwhise)
Learning other programming languages helps you understand architecture and programming concepts, that you can probably implement in your "old" programming language. Not learning them, doesn't mean you're a bad programmer, perhaps just a lazy one :P
1 - What has helped me is to categorize my insterests. Sure, they're connected in my brain and it's not like x is disconnected with y, we can always find a connection.. but I needed to separate them into categories to be able to manage them more easily because I don't need to tell you the state of the brain if you dump all of them in the one and only category most of us have which is labelled "Interesting" since we find every darn thing interesting.
Here's what I did:
I separated things into "Pillars". The way I think about them are Ministeries (I needed a really bureaucratic rigid structure to balance out the clustermess the brain is): Engineering, Business, Lifestyle, and Self Improvement.
Doing this alone has allowed to be conscious that I'm neglecting this category or that one, because now they have a name and I can measure stuff. Before, everything was just "Interesting" and it's not really easy to track down since they all blended together in a homogenous whole. It's like being in a bath and you're not really aware of when the water became cold. Tagging avoids that problem.
Compute how many hours you can dedicate for the whole stuff per week. There was a time I studied for 16 hours a day but it's not really the best course. It depends on your situation (work, etc). Most people say they don't have time but they really have a lot of time. A lot would spend hours on Facebook, then hours watching TV, and then complain and describe themselves as if they're not the "sitting facing a computer person". Most are on a 5 hours minimum wasted per day diet.
Each of those "Ministeries" gets a chunk of that time as a weekly budget. And this budget gets divided between the "Departments" making up that Ministery (say Engineering has Control Theory, Programming, Signal Processing, etc. Each one gets its weekly ration)
So imagine 40 hour per week for the whole 4 Ministeries. Say Engineering gets 20. From those 20, Control gets 5 hours per week, etc..
Thinking in weeks was important because there's only so much stuff you can fit in a day, and if you think in days, you wouldn't be able to see the whole picture, which is: Making sure you touch each of your areas of interests on a regular basis.
I'm sure you spent so much time on something really interesting, only to find that you completely forgot another thing that's really interesting on which you've spent a tremendous amount of time and of which you now recall nothing. Right? Sounds familiar? The feeling of the wasted time and still barely remembering a thing can make you punch walls.
So, instead of doing the same stuff for whole weeks or months.. You do many things that you visit several times a week. This sort of refreshes your cache with a high enough rate that you don't neglect a topic, but low enough for other things to be touched, too. In other words, you don't touch TOPIC 1 every single day, but even if you touch it every other day, the switching is fast enough you have the impression you're doing it every day.
This doesn't work if you have very few areas of interest, but works wonders if you have many. This is also why a week goes by "really fast", and why some people feel it's long (because they're not doing much. Some people actually do get bored).
Finally, limit things.
Not the amount of things you're interested in (although that helps.. But limit resources. I was interested in Python and was wondering which book was good, and where to start.. 4 years would pass. If I had read 10 pages per day of any book while I was trying to decide, I would've been much better at it right now.
This is where you have to be narrow-minded.. Want to learn Calculus? That one is tricky since most books suck and aren't my style, but pick one book and go through it. Even ...
How about a paragraph per day ?
No matter your level of sophistication, if you are making it through ten pages a day, you should probably switch to harder material.
The specific number doesn't matter too much, though.
If you get through one page of dense math an hour, you are doing well.
But, I agree that the material can be boring and too basic. This is why I have always preferred Soviet books (they get directly to the point and don't address stuff you should know) vs. US books (that will go back to high-school level to bring you up to speed, after which you want to sleep). Generalisation, of course.
The example I gave was to "learn" Calculus as in a Technical School (Undergraduate level). The material on that level isn't, in my opinion, hard to read. What do you think?