Podcast - Open Source Startup Podcast https://podcasters.spotify.com/pod/show/ossstartuppodcast
143 karma · joined October 31, 2019
X: @JoeMayo
Podcast - Open Source Startup Podcast https://podcasters.spotify.com/pod/show/ossstartuppodcast
1. One of the sites was dev.to, meaning that is one of the sites that it is crawling. You could write an article there, linking back to your site for more info. Just make sure the article is substantive in case they have an intelligent quality filter. Also, announce the article in social media and in your own circles to bring traffic, which might make it easier for the crawler to find, rather than pass over an article that's at the bottom of the stack because of less interest. Do this for any other sites that show up as references and let you post, though you should write unique articles because you don't want to spam the crawler.
2. Look for any sites that might have link lists. This might be old school, but when everyone was doing their own web sites, we had categorized link lists for related sites. Swapping links was good for everyone's traffic and good for the community.
Also, you might want to put an allow in your robots.txt to ensure you're explicitly inviting the crawler. Here's the details on ChatGPT, though you can learn more about other LLMs by visiting their site:
https://platform.openai.com/docs/gptbot
Essentially, do the research to find sites that are being crawled and try to figure out how to build paths for the crawler to find you in the link graph.
1. What type of development process do you use. e.g. agile, interative, or waterfall?
Some shops don't have processes at all, which is often a red flag. Be prepared to dig in a little. e.g. if they're agile, you might want to ask if they're Scrum or Kanban, have a backlog, sprints, standups. A lot of places say they do standups, but not much else. If they have a process that they think is working, they're often proud to discuss it.
2. Do you do unit testing?
There are various approaches and you might be able to dig in to find out if they do BDD, TDD, or afterwards. If they don't, it could indicate design issues from non-testable code, strong coupling, hard to find bugs.
3. What are your code reviews like?
Code reviews (properly done) can be a great way to help other people on the team, share info, and generally improve the quality of the code. Lack of code reviews, is a possible red flag that people aren't helping each other on the team and building a common team standard.
4. How good are application requirements and how are they communicated to me?
This could be good or bad, depending on how you look at it. It might be telling if you feel a negative vibe out of the response. That said, it's rare to have developers comfortable with a certain level of ambiguity. It's mostly a data point to see how the interviewers react to an often-contentious subject and gauging how you feel about the response.
Also, be prepared to discuss your experience in any area you bring up because it's common for an interviewer to aim the question back at you.
Also, if that's his dream - he shouldn't give up because today's programming positions are sparse. It could change dramatically in some amount of time. In the past, there have even been weirder anomalies in the market where programmer jobs were plentiful, while other jobs were sparse. The silver lining might be that by identifying where his passion is, he'll have time to be more prepared when the market is ready for him.
1. Prompt engineer - there's been a lot of talk about this, though I believe it's more extensive because businesses will need people to educate, manage prompt data stores, and assist with fine tuning.
2. Content management - as companies adopt AI with their own data, someone will need to manage the content going into the system including selection, privacy, and security.
3. Content Moderators - people who write/edit content will need to change their behavior about how the content is created and formatted, making it easier to ingest and lead to higher quality answers.
4. Content Creators - people who create content for the sole purpose of ingestion. This could be within a company, open-source/scientific research, or supporting vertical models.
5. Security Monitors - This is the person-in-the-middle who's watching/monitoring the system for privacy, safety, and security.
There are probably more, though this is what I'm thinking right now.
This was a pretty nice thing to do. I see this on SO occasionally and edit the post to remove the secret. While the secret is already out there, it signals to the poster that they should revoke/regen the key and a bit of a reminder to help them avoid doing it again.
Also, as other people inferred, management might be a problem. People often leave their jobs because of bad supervisors.
I agree that it's pretty awesome when you get to work with a great team of people, though you might want to watch the risks as you make a next move that is in your best interest.
https://www.syncfusion.com/succinctly-free-ebooks/assemblyla...
That said, it's important to pick your battles and be right on issues that are important to you. I've worked on a lot of different projects. The people who set up the project pick the standards and sometimes that's me. If I arrive on the project later, I typically take the stand of "When in Rome...". Watching the existing team's standards and adapting to that is a good approach most of the time because I'm doing my part to moving the team forward with consistency - and you'll often hear about the value of consistency.
Often, no one is wrong on these things and you just disagree. If you lose, disagree and commit. However, by having these discussions in a healthy way helps you and other learn and can be fun.
1. Domain experience - every business is unique and you need to put a given problem into context to see how a given solution fits the business.
2. Project requirements - most projects have barely intelligible requirements that change regularly - sometimes daily. The person would need to get up-to-speed on what that is.
3. One hour is a short amount of time to understand the task and complete it. The best you could do is try to understand and point someone in the right direction. People aren't machines and the need for flow is real.
4. AI code assistance requires oversight and understanding. You never want to generate code and check in unless you fully understand it. Code hallucination is and will continue to be a problem for the foreseeable future.
Here's a tweet from the Prof. Feynman account on X, offering another (if even humorous) perspective:
Option 1 is something you might want to do continuously. If you assume that you'll eventually be laid off (market cycle), at least you didn't wait until the last minute to have picked up a few new skills.
1. Do a Linked-In search for technical editors 2. Go on X (Twitter) to find a publisher (e.g. @OReillyMedia) and scan their followers/following lists 3. Visit Amazon.com and search for books similar to what you're trying to write and view their preview pages, which often include copyright info and contributors. Then you can do a search on those people's names on a social media site to make contact. 4. Amazon.com has a self-publishing service and offers resources to help authors in different aspects of the publishing process. I haven't done this and don't know for sure, but there might be a way to join that program and do a search for editors that might want to offer their services.
https://developer.twitter.com/en/docs/twitter-api/tools-and-...
I wrote and maintained one of the community libraries for years. However, I'm in a holding pattern, waiting to see what will happen in the future. The API has a free level, but it's only useful in limited scenarios. To actually accomplish what you're trying to do would require a paid subscription. You'll need to match your requirements to their pricing to see if the economics work out.
My initial dilemma with continuing working on my open-source project was whether it was worth it to pay the subscription to maintain an open-source project that I'm providing for free. Also, if hobbyists are priced out, I'm not sure how I feel about providing an open-source project for corporations that can afford the API fees while using my library for free.
Some cons, which might also be pros, are that you're running your own business and need to wear all of the hats. You manage your own payroll, buy your own supplies, and maintain your own benefits. You have to regularly find new work. You have to negotiate your own contracts and deal with customers who violate the terms. You do your own invoices and must ensure that the customer pays you. Sometimes, working through a recruiter can make some of this easier, but there are trade-offs where the recruiter wants to treat you like an employee too. You'll need to plan for gaps between work, meaning that you need to set aside funds in the business so that you can continue making payroll.
I've been independent for several years and it's worked out well for me. That said, everyone is different and it's good to get multiple opinions to compare with how it might fit your personal situation. I read books, talked to other people, and did a lot of research before taking the plunge.
Arizona, California, and Nevada recently reached a new deal on Colorado River water sharing and there are a few interesting discussions on HN about that. Right now, we have watering schedules of 2 or 3 days a week to keep our plants from dying and these days a lot of HOAs require approval (which is unlikely) if you want to plant grass in your yard (landscape plans require approval). Last week, the Governor signed a new bill that gave Nevada the power to restrict residential water usage if we get into a crisis.
So important and sets you apart from a developers who lack the ability to explain what they've done in terms of how a non-technical user/customer can understand.