This is the third part of the series: How to survive and thrive – a series for new developers to become better at their jobs. You can read the first two parts here and here.
In military, there is a term of “uphill battle”. That when you have to fight your way up a hill, when you enemy controls the top. It’s a very difficult fight and your chance of success is low. Any experienced military leader knows uphill battles are something you should avoid until there are no other options.
That also applies with any jobs. Including programming.
Then what is a branch in Git, actually? A branch in Git is simply pointer to the hash of a commit (which will be the HEAD commit of that branch), and a name of your branch, of course. That means creating a branch in Git is extremely cheap and is almost instantous.
Now if you look back at the branch tree in Git Extensions, you will see a linear tree. (It’s not something you usually see in your working environment, but we’re new anyway.). You can see that the name of the branches and the commit message are in bold.
For the commit, it means the commit is the HEAD commit of a active branch. A commit will always point to it parent (or its parents, in case of a merge). When you know the HEAD commit, you can know how does your branch look like, down to the initial commit (which has no parent).
Sometimes, you make a mistake committing something. A file can be missing, or the indentation is not perfect, or you had a typo in your commit message. If you are using some other source control softwares such as Team Foundation Server you’re done with that. The only option you have is to check in another change set to fix your previous one (in case you have a typo in your commit message, be done with that). Git is so much more powerful in terms it allows you to rewrite history.
To fix a commit, make a change, then commit as usual, but this time, Select the “Amend commit” checkbox:
The war of version control systems was over. Git has won. And that is not an over-statement. CSV, SVN, TFS were the past. Mercurial was close, but GitHub put the end of it. The popular of open source platform makes Git an unambiguous choice for almost every developer in the field . Even BitBucket, the service which once known for Mercurial, supports Git for now. If you start a new project today, Git should be your first and foremost option – well, unless your boss says otherwise.
But the end of a war does not mean everything else is settled. The war of Git clients continues. How many Git clients do we have? I lost count, but at least: Git bash (with comes as the default), TortoiseGit, SourceTree, and of course, Git Extensions. It reminds me a lot of the JavaScript frameworks’ war recently: “There are too many frameworks out there, let’s create a new one to rule them all”. Of course, Git clients’ war is in much smaller scale (You won’t see new Git clients every week), but that does not make it less intense. Git clients are used in a daily basis, and it really affects your productivity, and in some way, your moral as well.
Recently I stumbled on a tutorial named Learn git in 30 minutes. While there is nothing wrong with that tutorial, it’s actually pretty accurate, and clear and easy to follow – thumbs up to the author about the writing – I have great concerns about how should we learn Git.
Git is not that easy.
Don’t get me wrong, Git is a great tool, perhaps the greatest developers’ tool since C language. Where I work at, we switched from Team Foundation Server to Git two years and a half ago, and I’ve never looked back – Git does things right where TFS did wrong. It really helped my life, as a developer, easier.
But everything comes at a cost.
As powerful and flexible as it is, Git is also complex and easy to mess up. It can be your best tool, but it can also be your worst nightmare, when something goes wrong.
Back when I was young and mostly stupid, I discovered StackOverflow. The site struck me hard. There were a lot of “Wow” moments for a third year student. I still remember the first time I asked the first question, then even think about the questions to ask (so I can gain some precious reputation – yeah, I was young and stupid, remember?), and the first time I tried to answer a question myself.
It has been a long time since those days.
I still use StackOverflow, even at this very moment. But it’s on demand, instead of browsing it everyday as a habit. I search for a question, read the answer, possibly vote it up, then leave. Sometimes, when I have absolutely nothing to do, I try to review the suggested edits from other users. And that’s it.
I don’t entirely leave StackOverflow, I just don’t actively use it any more.
I’m not a security expert myself, not even close, but for more than once, I’ve been greatly concerned about the risks for having accounts in several websites. I wonder myself why did the developers there go with the decisions that bad.
It’s already bad enough to use HTTP on your register/login page . It’s even worse when you send me my password in plain text. Either the one I chose or the one you randomly generated for me.
Oh please, I know what my password is
And this has happened more than once. Each time, it raises my eyebrows higher and higher. I don’t want to rant here – but it takes great deal of ignorance or laziness, or both, do do such as bad practice about securities. Continue reading “Never send me my password”→
There’s a enormous number of books out there – (even I am writing a book!), so choosing the right books to read can be a difficult task. Yet it’s important because our spare time, is very limited: we still need to eat, sleep, socialize, take care of family and kids, while we have to spend significant time to write code and solve problems. How to get the right book and not regret spending time reading it?
There are many good books – but it’s best to categorize them into smaller groups:
Is the book only useful for a small group of developers, on a specific topic (such as C#, Javascript or Networking), or is it useful for almost every developer?
Is the book beginner-level, or does it require some experience to digest?
Will the content be still largely relevant after ten years, or will it be obsolete in just next few years?
Is it a book to read from cover-to-cover in one sitting (just kidding, I mean you should finish it when you start it), or to read chunk by chunk (read a chapter, stop for a while, read another chapter), or keep it around as a reference?
I have this criteria to categorize books myself:
Good books: A book which is on-topic and with accurate information, and in an easy to read and easy to follow style, the author(s) deliver their promises.
Great books: Good books give information. Great books raise questions. A good book becomes great when it makes readers think – not only about topics mentioned in the book, but also the bigger picture.
Legendary/Classic books: Great books which stand the time and still be useful after 10 years, or even longer. These are truly gems of their own and should be read, regardless of the topics. The topics might be obsoleted, but the thoughts/ insights are still relevant. They are battle-tested and no matter which field you are working on, you’ll still learn something from it.
Books you really should read
C programming language, 2nd edition
C programming language, 2nd edition
Not everyone works with C (myself included), but this book is still recommended over and over for developers. The book is pretty small, and indeed very easy to read and follow – it is widely accepted as one of the best programming books ever written, in terms of writing quality – and it provides a view of what is a function, how a program works, how are things connected to hardware-level …
If you ever write a programming documentation – and you will – make this a reference for writing style.
Code Complete, 2nd edition
Code Complete, 2nd editition
This book is considered must read for everyone, especially those who are new to software development, and re-read after a while. It’s a big book contains almost everything you should follow when you’re in the software industry – coding convention, naming, how to structure your classes … Get a copy and read it from cover to cover, if you haven’t, and re-read after 3-4 years to see how much you learned from it.
The Pragmatic Programmer: From Journeyman to Master
C# has never been considered as a cool language (fact: It was initially called COOL – C-like Object Oriented Language) – it’s a good language, very good indeed, but because of it is “created by Microsoft” and then “tied to .NET platform”, it lost the coolness to other languages – JavaScript, C, Scala, you name it.
The table has turned and the wind has changed. Microsoft has been making bold moves with all the open source projects that run multi platforms. Once known as the “evil” of software industry, Microsoft is changing their image to be good again. And with Xamarin being free – C# is the language to learn now – if you have not already. Being a very good OOP language with powerful functional programming features, and built on a mature platform and excellent tools and library, you can use C# for almost everything these days – mobile, desktop, server, and even client.
So how?
Visual Studio Community:
Visual Studio is simply one of the best IDEs out there, and while missing some of the features, Visual Studio Community is free – so it’s perfect choice if you are a student or simply learning the language. It can be downloaded from here:
I recently read this post F*** You, I Quit — Hiring Is Broken and found it interesting. If you have time – read it (and of course you should have, because this blog is far less famous than medium.com – the combination of page views for post in this blog is very likely to be much smaller than that single post).
I feel bad for the author for being in such situation – getting rejected 5 times in a row, is a hard thing to swallow. Especially when he is considered famous in developer’s world/ and has big passion in coding. And it’s not the first time, we hear someone rants about the hiring process, and it’s very unlikely to be the last. Let’s agree that the hiring process for developers might suck.
But then, it’s the way it works.
The first time no offer given, it’s probably their fault. The second time no offer given, it’s probably a bad luck. The third time no offer given, it’s probably your fault.
