500 days on Duolingo and it has felt like it was produced by ChatGPT 3.5 this entire time.
500 days of learning various bits & pieces and not being able to have a simple conversation - but I could probably say "There is a monkey in his backpack" if pressed hard!
I used to hate learning from actual textbooks as the conversations felt "dumb" or "forced" but that dumbing down as at least justified by having to progress from zero. Duolingo doesn't feel "plain dumb" but "weird dumb".
So yeah, if they replace their contractors (who must've used the cheapest models) with O3 or o4-mini-high or whatever, it should be an improvement!
Seasoned Product Engineer with 20+ YOE. Looking to help NYC founders scale beyond the MVP as your interim greybeard. I will clean up your code base and set you up for growth. Can help with infra (cloud and on-prem), performance, scalability, and agility. Past clients include Bloomberg, AMEX, Volkswagen. Tech stack includes Node.js, .NET, PHP, SQL and NoSQL.
Helping with maintaining and modernizing legacy code bases - PHP, JavaScript, .NET. As a seasoned generalist, I'll make sense of the weirdest stack you might have, document it, modernize it, and extend its ROI well past 2024.
Areas of expertise include: web performance, API integration, app deployment (on-prem and in the cloud), line-of-business desktop apps (.NET/WPF)
A good way to get started is not to ask "How do I become a freelancer/consultant" but rather "what valuable business outcomes can I deliver with my technical skills" and then find clients who have those problems and solve them.
Yes, this ignores the hard part of "finding those clients".
I know people with expertise in improving website performance, for example, and the mindset shift here is not to think about response times but rather improvement in conversion rates, decrease in shopping cart abandonment rate, etc. Clients don't really care about caching or asset preloading but they really, really care about squeezing the extra dollar from their website visitors. Help them make that extra dollar and you get to keep some portion of it.
Once you establish this foundation, getting to the right clients is easier than if you put yourself out there advertising "will write Python code for $$$".
So for instance, I wouldn't necessarily attend technical conferences / meetups but perhaps conferences where, I don't know, ecommerce website operators discuss issues that are critical to them. Those are your potential clients who can be perceptive to the right pitch. I think that technical conferences are a better fit if you're looking for a job and selling your resume.
Having said all of this, when I started out as a freelance dev, I did use Upwork to get some experience and reviews that I could later repurpose as testimonials on my website.
There's nothing wrong with hands-on freelance coding to get started somehow. It can be hard to define what specific business outcomes I could deliver with technical skills/existing resume, so getting some real-world experience can help with refining that. Always be on a lookout for that answer: once you understand "why" your clients keep paying you (hint: not for the code itself), you can find your niche and improve your sales pitch.
Finally: yes, it's critical to get out there and connect with people! Be it on LinkedIn, email, forums, Discords: you won't get clients unless you talk to people. Talking to past connections could also be a good way to find contract opportunities esp. if you've kept in touch over the years. Being a solo dev/consultant is 80% people work and only 20% technical work.
PS There's another way: you can ignore all of the above and apply to contract jobs (1099) using recruiters to get to clients. That's very similar to employment (clients tend to treat you just like staff) but you can potentially get better rates. I've been doing this for years with "success" but frankly, it's only marginally better than employment plus you get no benefits like vacation days etc. Real, actual consulting/freelance work can be a lot more satisfying if you can make it work!
I will augment your team to ship your product backlog on time while you're looking for your full-time hire.
My portfolio includes a lot of heavy backend lifting, integrations, and various plumbing. I've worked as a product owner and PM previously, which helps when you need to nail down the requirements. You'll get an adult senior generalist who gets stuff done without fuss.
Remote OK, will travel, will come to the office.
My visa only lets me work through my LLC, so no W-2, only C2C.
One thing that has worked really well for me in the past was joining Toastmasters International.
This is a group of people who are working on their speaking skills, but the effect goes way beyond improving one's public speaking.
I've seen many introverted people who could barely speak about themselves for one minute during the first "Ice-breaker" presentation undergoing a complete transformation within 6 months.
You'll meet once a week and exercise your communication muscle in a variety of ways. For instance, one fun part of Toastmasters meetings are brief, impromptu speeches on a topic you are given on the spot. There are also many less challenging roles in the meetings, and beginners typically work their way through those to get the experience and lose their fears.
I credit Toastmasters for becoming more engaging and less boring in a social setting ;)
That said, the key is what jamager said: listening and honestly caring about others. That should be the underlying value. I would emphasize that because it's also possible to get really good at public speaking and being very performative without actually connecting with anyone.
I made such transition years ago, and then went back to technical roles.
The primary benefit of doing this is that you develop a product and people-oriented mindset. All of a sudden, you are thinking about the "whys" instead of "hows". You think about customers and their pains and wants. This can be very rewarding if your natural disposition is to help others.
Technically, there's very little onboarding you'd have to do. Unlike programming, there's no language to learn, except English (or whatever language your business people speak). And by that I mean learning to speak the customer's language and using it to define the problem domain.
Long time ago, product managers (or business analysts, to be precise) would also use technical "languages" such as UML to describe the product. This fell out of favor in most industries. Agile mostly killed deep technical analysis (outside of code). It also killed use cases in favor of "user stories", which are a terrible way to describe a product in my opinion. But I digress.
Depending on your industry experience, you might have to do some onboarding in terms of understanding the market, customers, their purchasing decisions, and where do your company's products fit in all of this. I would start in an industry that you already know well.
All things considered, if you already have an offer and like it, trying on the product manager's hat will broaden your expertise and if you ever decide to go back to programming, this will be very valuable to you and your clients or employers.
SEEKING WORK | CET, 6 hours overlap with ET possible | Remote
I'll help your agency with software plumbing. Complex integrations, cloud deployment and performance, and backend code. Happy to get my hands dirty with work your people won't do.
Tech: Node.js, .NET, PHP, MongoDB, PostgreSQL... all kinds of web dev, plus desktop (.NET with WPF)
Cloud: Azure, AWS, Heroku (still a thing)
It's 2022, so yeah, I live and breathe git, CI/CD, test-driven development, all that good jazz!
More importantly, I approach all development with the clarified business outcomes driving everything I do. I won't give you any code that's useless and won't matter to your customers. Rather, I care about your ROI 24/7. You make or save money => I win a repeat customer. It's pretty simple.
SEEKING WORK | CET, 6 hours overlap with ET possible | Remote
I'll help your agency with software plumbing. Complex integrations, cloud deployment and performance, and backend code. Happy to get my hands dirty with work your people won't do.
Tech: Node.js, .NET, PHP, MongoDB, PostgreSQL... all kinds of web dev, plus desktop (.NET with WPF)
Cloud: Azure, AWS, Heroku (still a thing)
It's 2022, so yeah, I live and breathe git, CI/CD, test-driven development, all that good jazz!
More importantly, I approach all development with the clarified business outcomes driving everything I do. I won't give you any code that's useless and won't matter to your customers. Rather, I care about your ROI 24/7. You make or save money => I win a repeat customer. It's pretty simple.
During the 2000 and 2008 crises, there were massive layoffs, which impacted contractors just as they did employees.
In 2008, I contracted via an IT outsourcing company, and every week there was another announcement about a batch of colleagues being laid off. The firm's clients were canceling projects, and having consultants on the bench is very expensive.
Who knows what this will look like, though. If it ends up being like 2008 and clients start canceling projects, then yeah, it will get tough.
Not sure if I can give any generic insights on how to handle the down market as a contractor. A strategy that will work for you depends on your existing skills, niche, and network. As well as your appetite for risk.
If my appetite for risk were low, I would stick to my corporate "whale client" and ride out the recession on whatever boring project they've been running. I've done this during COVID.
But, a recession might also be a great opportunity to try something new. If what you do can translate into reduced costs for your clients (e.g., you know how to bring AWS costs down significantly), that type of expertise is very valuable when CFOs are slashing budgets).
I wouldn't let the lack of a relevant degree get in my way.
Sure, there are some EU countries where degrees are still being listed as a job requirement. Hell, when I contracted for a company in Munich, every other guy in the hallway had "Dr." in front of his name (and used it proudly in his e-mail signature).
Nevertheless, hiring can get very pragmatic when the company is hungry for engineers and few competent applicants come in.
Not sure exactly what the typical requirements are for a UX position. I'd imagine having a humanities background should be a huge plus, however. After all, this field is about human-vs-computer interaction, is it not?
Could she develop a small portfolio, maybe even using volunteer / non-profit jobs to get started? There's a good chance she could then use it to get in the door for better-paying UX jobs later, degree or no degree.
I've been deploying to the serverless stack on Azure (Functions, Service Bus), and have been mostly happy.
Azure gets a lot of hate around here and it's hard to disagree with some of the lived experiences.
That said, mine have been mostly positive overall. Yeah, the support isn't exactly stellar, yeah, the deployments are not 100% reliable (but close), but which stack has zero issues?
For me, the benefits vastly outweigh the issues.
For Functions, Service Bus, App Insights, I don't really care about the infra I once set it up. Everything is automated, from deployments to scaling when traffic hits. The team I contract for has 0 dedicated (Dev)Ops. Compared to another project where we used k8s, that's a big win - there, we had 3-4 dedicated k8s experts on staff to keep the lights on.
Some services that we use on Azure are not really serverless, like the managed Postgres. That's sub-optimal as the database can very quickly become the bottleneck and can't keep up with the autoscaled function instances. I hope that what Neon[1] is trying to do - truly serverless Postgres - takes off and I wish Azure had that.
The tooling and integrations that Azure has is also a big win in my book. For instance, migrating a static website to Azure Static Web Apps (omg why didn't they just call it "Pages"?) is super easy. You get automatic deploys from main/master and automatic preview environments for pull requests. All it takes is a simple Github workflow. I don't think I would want to manage my own infra for that.
The downside of the serverless model is that once you hit a bug or a limitation of the platform, all you can do is open a ticket and hope for the best. Whereas if you own the server, well, you can dig in, obviously.
For me, once I understand the trade-offs and serverless comes out ahead, I go all in. YMMV.
SEEKING WORK | REMOTE, EU and US-East timezones | Back-end, integrations, performance
Hi there! Need some help with complex backend topics, integrations, or your web app deployment and performance? I can plug into your team on a part-time basis (up to 20 hours/wk) and get the ball rolling.
Tech stacks I use routinely:
- Node.js / Typescript
- C# - ASP.NET Core, WPF
- PHP - Laravel
- Docker, k8s, AWS, Azure, Heroku
Recent client highlights include:
- billing system for a car-sharing operator in the EU (Node.JS, Typescript, Postgres, Azure functions)
- backend & integrations of a large content website for a US credit card company (PHP, Heroku)
- backend dev & enterprise integration for an insurtech startup backed by Munich Re (Node.JS, Typescript, Mongo, AWS, k8s)
Drop me a line if you need someone who is a quick study, will grok your business and the big picture. Raw developer firepower included.
Now, I don't think that a hustle must necessarily equal "passive income." It can be a freelancing hustle, or a product hustle, or a SaaS hustle, but there's nothing passive about them.
It takes time to come up with an infoproduct, for example, and you've got to promote it, build your circle of followers, etc. And even if you do everything right, there's a huge amount of chance/luck. Your product might take off, or it might crater (or anywhere in between). Either way it's a lot of work.
Anyways, just my 2c, and good luck with your book!
I have quite some experience working in Waterfall orgs. Starting around 2012, I noticed Scrum becoming the default. But, not much changed, just the ceremonies are called differently!
At many orgs, Scrum is just a thin veneer over top-down planning. It gives the developers an illusion of freedom while being in practice yet another instrument of control.
Not that there is anything wrong about wanting to control your org's processes! Could we just be more honest about it?
For example, the daily standups are advertised as a tool for team synchronization. More often than not, it's status reporting with the PO/SM intently listening and probing. A well-gelled team will obviously sync itself on the go without any need for this ceremony.
The worst offender is often the retro. I've been to way many retros that were completely led by the manager (PO, SM). But even if the manager is out of the room, what's the point?
A tightly knit team won't need a biweekly retro. It solves its problems as they arise. I would prescribe retros when the team is freshly formed and abolish them as soon as it gels. Then, let's meet offsite once in a while, hang, shoot the shit, and discuss the big picture.
I think that overall Scrum has brought some benefits and some agility to sw development at big orgs and maybe it's only there where it still provides some value. I'd be interested to learn whether startups of today use it at all?
There are two general paths that software devs can take:
- do generalist software augmentation contracting, where you are essentially an employee but paid better (and fired faster but that goes both ways)
- specialize, build expertise, and do consulting - selling your brain, so to speak, as opposed to providing an extra pair of hands
The advantage of the contracting route is more predictable income, esp. if the projects take months or even years to finish. That's quite common in Europe if you contract for a Fortune 500 equivalent company like Volkswagen. The corporate "digitalization" projects run forever and a contractor can successfully embed himself or herself there for as long as is enjoyable (and profitable).
There are downsides.
First, you do not develop your sales and marketing muscle when taking on full-time staff augmentation roles. In Europe, it's common to get these gigs through recruiters, and so you don't even own and manage your relationship with the client.
Second, it feels like employment because it essentially is. You attend all the Scrum ceremonies like everyone else. Clients expects you to be available during the working hours and has all the other expectations they have for their staff employees.
Third, it's hard to scale this "business". Since you are a staff engineer, just with a different contract, the client does not see you as a consulting partner, so offering additional manpower to the client could be a tough sell.
On top of that, it's easy to just "go with the flow" and accept whatever gig the recruiter calls you about, provided it pays OK. Then, you look back at your portfolio and it's a hot mess!
This has been my experience doing staff augmentation in Europe for 10+ years. I am transitioning away from that, and the journey has been quite taxing, mentally. Like going to gym for the first time in years, only now it's your brain that needs training - it can hurt for a while.
One more point:
I see some people professing their hate for sales.
Actually, you do sales, too, when you sell yourself to the recruiter or your future boss. Sales is inevitable and we engineers better be GREAT at it.
I think sales in consulting can be even enjoyable, and I do love this aspect of the work. It just can't be the "used car salesmanship" type of sales. You gotta listen, really listen to the client, grok their situation and build baseline trust. Then the sales conversation feels more like an advisory session. But to get there, I think, requires building expertise and some level of specialization. How much of either, I am not sure.
Hopefully this helps a little.
PS I strongly recommend following Jonathan Stark of the "Hourly Billing Is Nuts" fame. It's a great antidote to a lot of questionable freelancing advice one can find one the interwebs.
https://github.com/teekay/dictum
Currently dogfooding and evaluating whether it helps in the long term or not.