I am a technologist and a tech team leader - my work revolves around helping companies and the engineers that work for them to create maintainable, extensible systems to solve their business needs.
My personal engineering skills and experience have coalesced into my self-identification as a Polyglot developer. I work in an variety of OO and Functional languages and at the core of everything I believe that there is great value in creating small components that do one thing well and then combining those components to produce large effects.
Nothing here yet.
No blogs yet.
I definitely code for fun. I tend to work on side projects and I also spend an amount of time each month learning new things, whether that is new approaches, new technologies or new languages. I find coding in my spare time very rewarding - I almost always work on things that help me out / solve a problem of my own, and doing these things allows me to improve the skills that I take into my professional life.
I would have to recommend looking at functional approaches to data, even if you are not adopting an FP language. There has been a movement towards functional style operations in JavaScript in recent years, with libraries like Underscore, and you can make use of functional approaches in Python with functools. Every developer can benefit from understanding map, reduce, filter, first, rest etc.
OK, here is the honest truth... Recruiting is hard. If you don't have a yardstick by which to judge candidates then you are just taking them at their word that they know anything at all about anything that they say they do. Some people / organisations use the chalk'n'talk, solve this problem approach just to weed out the people that talk a good game but don't really understand shit about shit. No one, no organisation worth their salt is using it as the prime measure by which they will choose to make you an offer or not, as software engineers and their skills and experiences cover a far wider gamut and are far more complex than these kinds of tests / approaches uncover. After all, how can you be sure that they are not just simply incredibly nervous? You might be casting out a very fine engineer just because she or he finds it much, much harder to think about code without a keyboard and a computer - not that they need the internet or anything like that but simply that they think better with a console open in front of them. When I recruit I DON'T use whiteboard algorithm tests, mostly because they overly favour recent graduates of "hard" computer science courses, and I have worked with far more software engineers who did not study CS than those that did, and because they can be prepared for in a superficial manner that does not necessarily show understanding. There are loads of books on "Cram for Whiteboard Questions" etc. - go and look on Amazon - there is little or no point using them, there are methods to get ready for them. I get candidates to carry out a hypothetical coding task, one that should take no more than 4-6 hours, before I see them in person, and if their code is not up to scratch they don't get the face to face interview. That way the interview can be about their values, their understanding of best practice, their thoughts on the industry, new innovations, etc., rather than an on the spot explanation of a / the "knapsack problem" or Djikstra's Algorithm. What I would say is that you would be surprised the number of uses that Data Structures and Algorithms can and will be put to use in the roles that you think don't need them, and if recruiting for a more senior role I will try to gauge the level of understanding amongst the candidates that I choose to see face to face on some of these issues, because a shared understanding of the CS domain, and a common lexicon about things is part of a team / organisation fit, if nothing else. If you can't explain to me the difference between an Array and a Hash (Associative Array in PHP, Dictionary in Python, Hash in Ruby, Map in Clojure etc.) then I am likely to make some not unreasonable assumptions about the depth to which you have considered your craft. More to the point, why have you not spent a couple of hours on finding this shit out, seeing as you make your living out of it. General rule of thumb, if you don't get a job because of a bungled whiteboard exercise, make sure that you learn from it, there are plenty of companies that still recruit this way, but try to work for people who've realised that there is more to it than that. :-)
16 years professionally, but been programming computers on and off for 33 years. Learn all the time. Don't let yourself fall into the "Right, now I am a Ruby Developer" (for any language) trap. Learn new languages, learn new ways to use them. Do challenging stuff, with other people for preference. Avoid PHP if you possibly can - it will allow you to form and get away with bad habits. Never reject a language on first look because you don't like the look of the syntax - you may get over your initial reaction quickly and discover something marvellous beyond your initial prejudices. (e.g. "All those parentheses in Clojure are just confusing - if you can see past it this drops away in hours, particularly once you add paredit to your dev environment of choice and you are just left with an amazing development experience) Learn Vi(m) AND Emacs - they are both awesome and both well suited to different tasks. Use the command line - it's hard to learn to be productive, once you are you will wonder why everyone else f's around in the GUI and with IDEs. Having said that if you are working on a large project have a good IDE (IntelliJ or similar) on hand for when you can save a lot of time by using one - following relationships between calls and their respective classes / func-libraries etc. Write Unit Tests. Bake in your deployment approach from the beginning and make build->test->deploy a 1st class citizen in your projects. HAVE FUN! (otherwise what is the fucking point)
Hi there, nice to make your acquaintance :-) I am a total beginner with Cljs but I am reasonably proficient with Clojure - built a couple of things with it etc. I am hoping that there will be a Clojure Node on here soon, it's in the request queue.
That's a good point Joe. My only concern at the moment is that nodeJS is still not really ready for primetime imho, but I realise that the Jury is out and that some people flat out don't agree with me, so it's all a bit subjective ;-)
We use prefixes, so hotfix/ , feature/ etc. and we tend to use ticket numbers, so feature/EN-333 and we encourage short descriptive suffices, so in the end something like this -> feature/EN-333-fix-sorting-by-price
Honestly if you are starting out on your own and you don't have to fit in with a team of existing PHP developers then go with Python or Ruby (or perhaps Groovy if you like the JVM) instead. PHP is not a language that I would recommend to anyone who already knows how to program. With Ruby you've got Rails for big heavy projects, Padrino and Sinatra for lighter weight stuff, and with Python you have Django and Pyramid when you need "batteries included" web frameworks and Flask and Bottle when you need something lightweight. Groovy has Grails (like Rails but for Groovy) and Ratpack for the more lightweight approach. Don't misunderstand I've had PHP jobs on and off for the last 16 years and it has been good to me, but once I started working in languages like Python and Ruby as well I started to realise the downsides of PHP. Also, if you are going to do freelance webdev you are going to need to focus some of your attention on JavaScript; some things need to be scripted in the UI. That and you will need to look at CSS, specifically CSS 3, and HTML, specifically HTML5 these days, but XHTML 4 as well. Good luck - if you steer clear of PHP you will have a much happier time...