Everyone is different, so it's hard to tell if someone's recommendation fits another person. Here's what I do though to manage my experience. I have a private list (that no-one can see) and add only a select group of people. That list changes over time as my own interests and other people change too. This weeds out destructive and negative content and helps interact with interesting people.
MS Press recently released Charles Petzold's 2nd edition of Code. It provides insight into the evolution of computers, including Boolean logic and binary code: http://www.charlespetzold.com/books/
- VSCode: JavaScript/Python dev
- Notepad++: Fast copy/paste, JSON formatting, document viewing, or converting from a rich-text format to plain text for pasting in a web comment. Because it also saves tabs, it's helpful for temporary sticky note type text. I rarely ever code here.
- textEdit: On Mac because it's easier to type here and then paste into HN comment.
- Visual Studio: C# development
In recent times, it hasn't mattered a lot and you were good as long as you could write the code that people asked you to. However, the market looks like it might be changing with hiring freezes/slowdowns and layoffs here and there. If we do hit another recession, where we have to compete for jobs, the rules change. Anything that you do from certifications to MCS and any other way to set yourself apart from the crowd will be a benefit. I always felt like the MCS was beneficial because, unlike the bachelors, you're concentrating nearly exclusively on computer science, which is pretty cool.
Doing the search and looking at the company is time consuming, but works. You have to do the research. Some of the larger companies are like Accenture, Neudisic, and ThoughtWorks. Some of the better-known recruiting companies also do project work and hire full-time (as well as contract). An interesting surprise is that some companies like Amazon and Microsoft also have consulting arms. What's might be easier though is to find a local or regional company that does consulting/project work and they might take more effort to find - more research. Sometimes, if you find a consulting company, they may take your resume and keep in touch in case they have something for you later. So, it's good to reach out even if they don't have an exact match at the current time.
One approach is to talk to consulting/contracting companies. They usually have clients using different technologies. This might give you an opportunity to lead on the tech you're most familiar with (immediate value to the company) and still be able to learn new skills. People with the capacity and desire to pick up new technologies can be valuable in consulting/contracting roles. Also, if you explain what you're looking for in your cover letter, it might help screen for companies that match - avoid wasting time on interviews that won't go further.
I think the partition of Junior vs Senior won't fully capture the decision making process on who goes or stays. While only time and effort will change your skill level, there are other traits that contribute that you might be able to change:
- Potential: How fast has this person picked up since they were hired?
- Intelligence: Related, but natural smarts is still a plus.
- Personality: How much are you a fit for the team?
- Reliability: Whether a manager know they can give work to you and it will get done.
- Work Ethic: Available when they should be and make the most of their time.
- Communication: Whether a person can present complex concepts in a coherent manner.
Essentially, you want to make yourself so good at the things you can do that whoever is making the decision has a really hard time letting you go.
It used to be said that Microsoft v1.0 products should still be considered beta, which is fine for early adopters. However, a lot of folks who preferred a more solid product would wait for the v1.1.
I used to teach certification courses and people attend for different reasons. A common reason is that the test covers the things that you should know to be successful in a given technology and the exercise of studying to know those subjects improves your skillset. Some people just love learning and want the sense of accomplishment from hitting a milestone. Some people came from the government contracting sector where the number of certifications reflected well on contract bids, so the company encouraged their people to get the certifications. Another reason is that in a competitive market, where two resumes, experience, personality fit are similar, the certification might be the deciding factor.
One of the ways to find out is to visit the job sites and do research. I like Indeed.com. Linked-In is another decent place to search. If you post a resume, recruiters will likely reach out and be happy to discuss what they're seeing in the market regarding your skill-set/interests/desired compensation. You might also try Meetup.com to see if there are any groups with people interested in what you're looking for because direct referrals (from networking) mean that you might not have to share your rate with a 3rd party.
Also, on the first day of each month, there's a HN thread for hire/hiring/contracting that you can read or add yourself to.
I did this course too and thought it was pretty good. A couple notable parts that I liked was that he explained the math (so that non-mathematicians can understand) and had guest interviews for inspiration.
I totally agree with the premise that while technical knowledge is crucial, it shouldn't be the determining factor of whether someone is a Senior Engineer. What is also important is the ability to communicate effectively and mentor other developers.
One of the easiest ways is Meetup.com. If you don't find a community that works, you can create your own. Twitter is helpful for finding people and their new Circles feature looks interesting. I don't use Facebook much these days, but have joined several groups in the past. It's a lot of work, but I also once (pre-Twitter) built my own website with a forum and posted articles and tutorials that got pretty good search engine traffic and pulled like-minded people to my site.
Ethics are very important because the products we create have such powerful consequences. It's common to see engineers so excited about the product they've created (myself included) that they overlook the additional problems they've created. Recent examples are with AI models built with historical data (hiring, loans, or other competitive decisions) that discriminates against groups of people. An ethical approach would be to include these considerations in the data analysis phase. It's not that most developers allow this to happen intentionally and having an ethical mindset is one of the things we can do to avoid problems.
1. Audience analysis - who are they and what do they want out of the course? This will guide your perspective as you manage the trade-offs of what to include/exclude and how you teach.
2. Outline of the major topics to cover. Start by just listing topics and pull the major topics to the top. Keep the others around in case they fall under the others or suggest something that you could follow-up with at the end of the course.
3. Arrange the major topics from the most basic to more advanced. This makes the course an easier on-ramp.
4. Also consider if the first/easiest topic is basic enough. It's easy to assume that people have certain knowledge, but you would be surprised at how covering basic material, if even quickly, can be appreciated.
5. Visit each topic and break them down into sub-topics (steps), from basic to higher level, that fit under that topic. What is key to know about this topic.
6. Start adding content and illustrations to sub-topics, imagining how you would teach each. What should they know and how is it easiest/clearest for you to communicate this information?
7. Iterate over all topics because you'll find some that should be in other places.
The tool you use to get started might be the easiest and most familiar to you (text, word, ppt, etc). That said, by the time you get to step #6, you'll probably want to be in PPT.
Patterns are a pretty normal tool in the work I do. I use Strategy a lot and various forms of Factory on occasion. Others include DTO, Repository, and Specification. Mostly, the libraries and frameworks I use are based on patterns, such as Builder for object initialization, Iterator for collection, and Template for UI development. When I have a new problem to solve and the solution doesn't reveal itself right away, I'll review different patterns to see if there's an approach I haven't thought of.
Sometimes the result is a pure match to the pattern. Other times, I just adapt to something close to a pattern because I'm modeling a real thing and reality often doesn't fit the mold of a pattern in a book. I believe the GOF book acknowledges this so that people will know to be flexible and use Patterns as a tool, rather than an exact prescription.
Sometimes it's better not to give yourself a title. Just say Software Engineer, which is fair because you have a degree. Because you've recently graduated, if you call yourself Senior, there's potential for some people to look at your resume and have doubts, which could result in not being interviewed if they have questions about your honesty. You might actually have the capability and skills of a Senior developer and a safe approach might be to just get the interview and pleasantly surprise them by exceeding their expectations.
Writing anything, it's useful to get into the mind of the people who will be using the software. Who are they, what type of work do they do, and why are they looking at the page are a few examples of questions to ponder. Step into their shoes and pretend to look at your page from their point of view. One of the things I've found useful when starting from scratch is to just put something out there and then keep the discussions/issues to communicate with people. If you have enough traffic, folks will ask questions. Each question has the potential for a conversation that lets you understand who these people are and what they're looking for. If you have enough interaction, you'll start seeing patterns (FAQs even) for areas that you can improve in the readme file. After you begin to address the things people care about, you'll see a decrease in the amount of questions in the covered areas, indicating that you're improving the documentation. Essentially, what I did was examine the audience, find a metric to measure progress, and iterate in the hopes of improving the docs.
For me, the primary motivation is giving to the community. I believe that doing this makes the world just a little better in one way or another. For every person who does this, the effect multiplies. Think about how someone else's open source made your life better. You could do that for other people too.
Some emails have unsubscribe links and I use them. Occasionally, I respond and ask them to take me off their list. Also, I don't let it bother me because it sucks worse when no emails come in.
A lot of people and projects that I've been on don't have tests at all, let alone TDD. I always ask about it when coming on-board and people feel like it's something they should do, but there's something holding them back. Either they aren't convinced of the benefit, think it's too much work, have an idea that they can't achieve some level of perfection, or some other belief that keeps them from getting there. IMHO, going from nothing to TDD is a huge jump and I'm often successful just convincing people to do testing whatever way possible. After that, it's a process of waiting for the right moments in time to point out the benefit that the tests gave. e.g. "Holy cow, imagine what this refactoring would have been without tests!". People won't be convinced until they see the benefit themselves. Along with testing, it's good to do PRs so that developers can remind each other to add some tests to build the habit. I feel like just doing tests is a fair compromise and moves a project in the right direction. As far as advocacy goes, I'm neutral on BDD, TDD, or just do tests because there are opinions all over the map on this and I think it's better to get team consensus, rather than alienate people.
Part of the OAuth protocol requires a timestamp, which needs to be within the same 5 minutes of the Twitter server. If the timestamp is out of these bounds, Twitter returns HTTP 401 Unauthorized responses and nothing works.
In addition to language, it might be helpful to explore the type of coding you want to do. e.g. Web, Mobile, Cloud, etc. One of the things you can do is peruse some free resources to see what's available and how you like it.
They have curriculum on Web development with JavaScript and React, which is a popular framework. They also have data science material with Python and related tools.
I'm in the Microsoft space, which has a lot of opportunity and they have free courses on everything you would want to do. You can even open a free Azure account to practice cloud development.
The acquisitions editor for the publisher of my first book cold emailed me. It was quite the shock and I almost thought it was a joke. Good thing I replied.
Not sure why more people didn't mention this. I make sure that I have a minimum of 3 months of liquid cash available. Generally, I keep it at 6 months. Not only is that a nice buffer between jobs, but it also gives me confidence that I don't have to take the first/worst job that comes along next.
On one project, I use *.md files. Benefits include easy readability on GitHub (or other site that renders Markdown) and I treat documentation the same way as code and it goes through PR. Another way I do documentation is via GitHub pages, where I can give it a URL and it works like a normal website.
I go along with what the other people are doing. If most of them have cameras on, that's what I do to - if they're off, I'm off too. I'm non-judgmental about anyone's preferences one way or the other and accept people for who they are. Times that I tend to turn my camera on, regardless of what anyone else is doing is when I meet a person for the first time or need to interact with customers or other organizations outside of where I'm working.